[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH XEN v6 25/32] tools/libs/gnttab: Extensive updates to API documentation.

On Wed, 2015-12-09 at 12:41 +0000, Wei Liu wrote:
> > + */
> > +
> > +/*
> > Â * Grant Table Interface (making use of grants from other domains)
> > Â */
> > Â
> > Âtypedef struct xengntdev_handle xengnttab_handle;
> > Â
> > Â/*
> > - * Note:
> > - * After fork a child process must not use any opened xc gnttab
> > - * handle inherited from their parent. They must open a new handle if
> > - * they want to interact with xc.
> > + * Returns a handle onto the grant table driver.ÂÂLogs errors.
> > + *
> > + * Note: After fork a child process must not use any opened gnttab
> > + * handle inherited from their parent, more access any grant mapped
> > + * areas associated with that handle.
> > + *
> And this could use the same cloexec trick as you do in other patch for
> privcmd.

I think this statement "do not use the handle" still stands regardless of
the underlying fd being cloexec'd.

However, this did make me think about a comment elsewhere, specifically the
various instances of:
Â* This is the only function which may be safely called on a
Â* xen<foo>_handle in a child after a fork.
for several xen<foo>_close() functions.

This is not really true if the fd is cloexec, since then _close() will
either fail (EBADF) or, worse, close some other freshly opened file

There seems to be two choices here, either require all osdep backends to
make their fds O_CLOEXEC (which might involve tolerating a racy
fcntl+FD_CLOEXEC pattern after open on some platforms) or don't set
O_CLOEXEC ever and declare that the application is responsible for closing
after fork, and for taking care of the corner cases themselves in
multithreaded applications.

The former seems friendlier to me, even if some platforms need to use

Hrm, maybe I can extend the atfork trick to cover the open+fcntl bits.
Hopefully there is no issue with using pthreads from each of the affected

So, I think the advice in the comment would then be:

    If you fork and then exec then you must not (and need not) call _close()
    or any other function on the handle.

    If you fork but do not exec then it is permissible to call _close(), but
    it is not permissible to call any other function on the handle.

Need to think about that wording.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.