[git commit master] CLOEXEC: use open(CLOEXEC) if exist; do not check fcntl(FD_CLOEXEC) failure

Mike Frysinger vapier at gentoo.org
Sun Sep 6 15:27:26 UTC 2009


On Sunday 06 September 2009 11:01:26 Denys Vlasenko wrote:
> On Sunday 06 September 2009 16:44, Mike Frysinger wrote:
> > On Sunday 06 September 2009 06:07:04 Denys Vlasenko wrote:
> > > On Sunday 06 September 2009 08:18, Mike Frysinger wrote:
> > > > On Saturday 05 September 2009 18:05:32 Denys Vlasenko wrote:
> > > > > On Saturday 05 September 2009 23:55, Mike Frysinger wrote:
> > > > > > On Saturday 05 September 2009 17:55:26 Denys Vlasenko wrote:
> > > > > > > >On Saturday 05 September 2009 16:04:36 Denys Vlasenko wrote:
> > > > > > > >> +#ifndef O_CLOEXEC
> > > > > > > >> +# define O_CLOEXEC 0
> > > > > > > >> +#endif
> > > > > > > >
> > > > > > > >it should be defined by the C library headers.  if it isnt,
> > > > > > > > then the port needs updating and the build should fail.  so
> > > > > > > > please drop this cruft.
> > > > > > >
> > > > > > > You probably was thinking about FD_CLOEXEC. :)
> > > > > > >
> > > > > > > Yes, FD_CLOEXEC must exist.
> > > > > > >
> > > > > > > O_CLOEXEC is a new, Linux specific open() flag.
> > > > > > > And currently it is not yet defined, since there are many
> > > > > > > old kernels in the wild which won't understand that.
> > > > > >
> > > > > > no, i'm thinking of O_CLOEXEC.  i know what the flag is for, and
> > > > > > it should be defined in bits/fcntl.h for every port.
> > > > >
> > > > > Currently, it is not defined on any arch:
> > > >
> > > > then you fix/update the arches instead of ignoring the problem and
> > > > sprinkling cruft everywhere
> > >
> > > Defining O_CLOEXEC does not necessarily make it work.
> > > Kernel should be new enough to understand it.
> > >
> > > If the program will be run on an old kernel, open() with O_CLOEXEC
> > > will not work as expected.
> >
> > it'll work just fine.  read lkml about open() behavior and unknown open()
> > flags (tip: they get silently ignored).
>
> Yes.
>
> But this is not what expected. We do want those fd's to be closed on exec.
> If we feed O_CLOEXEC to open and it gets ignored, we have non-CLOEXEC fd
> and then we get stray fds in child processes. Not good.
>
> When I saw O_CLOEXEC ifdefed out in the headers, I understood it like
> "we will enable it later, when O_CLOEXEC-enabled kernels will be widely
> deployed". I think it's a correct approach.
>
> Another way is if we make it a uclibc config option "assume O_CLOEXEC
> works".
>
> Unconditional usage of it would be dangerous right now, IMO.

this concern doesnt change anything wrt what i've said.  if you want to handle 
this case, use the __ASSUME_* framework like everyone else.  i.e. copy the 
definition of __ASSUME_O_CLOEXEC from glibc into our kernel-features.h and use 
that to determine whether you need to use fcntl() manually.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20090906/c022af41/attachment.pgp>


More information about the uClibc mailing list