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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v6 25/32] tools/libs/gnttab: 
Extensive updates to API documentation."):
> On Wed, 2015-12-09 at 13:50 +0000, Andrew Cooper wrote:
> > An _open() call must be matched with a _close() call.
> 
> This is not safe after an exec though, since the fd will be closed, or
> perhaps even reopened already (although the requirement could be to call
> _close before doing such things as opening any fds, at which point close
> could silently handle EBADF).
> 
> > In the case of fork but no exec, there should be a _close() call in both
> > the parent and child, to free other resources.
> 
> In the parent I assume you mean "at some point (or call exit())" rather
> than in some way associated with the forking, because the parent is
> entitled to keep using the handle.

There seems to be some confusion in this subthread between fork and
fork+exec (and, for that matter, exec).

I think the grant fds can sensibly be marked CLOEXEC but that it
doesn't matter, because I think the openness of such an fd after exec
can never cause anyone a problem.  (CLOEXEC is needed for sockets,
pipes, etc., where the very openness of the openfile has semantics
which are detectable by the peer.)

There is no problem with CLOEXEC causing any bad EBADF or fd reuse,
since the post-exec process has a completely fresh address space so
cannot have any xengnttab_handle* or whatever.  It has nothing on
which to call xengnttab_close (or any other call in this file).

(I'm assuming throughout that no-one has conspired to cause the gnttab
or gntshr library to get fd 0, 1 or 2.  If some did so conspire then
they deserve to keep all of the resulting pieces.)

But conversely CLOEXEC doesn't help with fork at all.

Ian.

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