Re: [Xen-devel] [PATCH XEN v6 29/32] tools/libs/call: Use O_CLOEXEC when opening /dev/xen/privcmd on Linux

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-12-09 at 16:17 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH XEN v6 29/32] tools/libs/call: Use O_CLOEXEC
> when opening /dev/xen/privcmd on Linux"):
> > We stick with using FD_CLOEXEC on the legacy /proc/xen/privcmd
> > fallback device since it was present in older kernel where O_CLOEXEC
> > may not be assured.
> 
> This is a lot of effort and may not be needed.ÂÂI don't object, but
> some of the statements are (I think) rather too fierce:
> 
> > +ÂÂÂÂ/*
> > +ÂÂÂÂÂ* This file descriptor is opaque to the caller, thus we must take
> > +ÂÂÂÂÂ* responsibility to ensure it doesn't propagate (ie leak) outside
> > +ÂÂÂÂÂ* the process, by using CLOEXEC.
> > +ÂÂÂÂÂ*/
> 
> For example, I don't think this is a `must' at all, although not
> propagating irrelevant fds is (nowadays) seen as polite.

Right, this bit was actually (mostly) code^Wcomment motion.

I'll happily update it to say polite rather than required.

I did a bit more investigation of O_CLOEXEC and found that Linux introduced
it in 2.6.23 (October 2007) which seems to be old enough that we should
just use it anywhere we feel it necessary.

Jan did mention (on IRC) that while he doesn't use any kernels so old, he
still occasionally builds on userspace which is old enough to lack the
definition, hence I would do #ifndef+#define.

Roger, I see that open(2) on FreeBSD mentions O_CLOEXEC too. Do you know
when that arrived and whether it is something we can assume these days?
I found a posting of the patch inÂhttps://lists.freebsd.org/pipermail/freeb
sd-fs/2011-March/011021.html, but I don't know when it landed or when it
became something code could assume.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel