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

[Denys Vlasenko]

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.
--
vda