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

[Denys Vlasenko]

On Sunday 06 September 2009 17:27, Mike Frysinger 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.

Then I do not understand what exactly you are saying.
--
vda