This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [PATCH] Assume that O_CLOEXEC is always defined and works

From: Florian Weimer <fweimer at redhat dot com>
To: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, libc-alpha at sourceware dot org
Date: Tue, 18 Apr 2017 11:39:26 +0200
Subject: Re: [PATCH] Assume that O_CLOEXEC is always defined and works
Authentication-results: sourceware.org; auth=none
Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com CC10061D35
Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com CC10061D35
References: <20170413202510.40B78403B991F@oldenburg.str.redhat.com> <9fb79f9b-0865-6849-66a8-9fb07b99d508@linaro.org>

On 04/17/2017 09:11 PM, Adhemerval Zanella wrote:

    if (!do_cloexec)
-#ifdef O_CLOEXEC
      /* Undo the effects of the pipe2 call which set the
         close-on-exec flag.  */
      __fcntl (parent_end, F_SETFD, 0);
-#endif

Why can't we issue the __pipe2 as '__pipe2 (pipe_fds, do_cloexec ? O_CLOEXEC : 0)'
and get rid of this logic here?

There are two descriptors. The descriptor for the subprocess mustalways be O_CLOEXEC in the parent, so that it's not captured by aconcurrent fork and inherited across execve there.


Thanks,
Florian

References:
- [PATCH] Assume that O_CLOEXEC is always defined and works
  - From: Florian Weimer
- Re: [PATCH] Assume that O_CLOEXEC is always defined and works
  - From: Adhemerval Zanella

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]