On Tue, Nov 14, 2017 at 12:15:42PM +0000, Ian Jackson wrote:
> Closing the fd before unhooking it from the list runs the risk that a
> concurrent thread calls xentoolcore_restrict_all will operate on the
> old fd value, which might refer to a new fd by then. So we need to do
> it in the other order.
>
> Sadly this weakens the guarantee provided by xentoolcore_restrict_all
> slight, but not (I think) in a problematic way. It would be possible
slightly
> to implement the previous guarantee, but it would involve replacing
> all of the close() calls in all of the individual osdep parts of all
> of the individual libraries with calls to a new function which does
> dup2("/dev/null", thing->fd);
> pthread_mutex_lock(&handles_lock);
> thing->fd = -1;
> pthread_mutex_unlock(&handles_lock);
> close(fd);
> which would be terribly tedious.
>
> Signed-off-by: Ian Jackson <ian.jack...@eu.citrix.com>
Acked-by: Wei Liu <wei.l...@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
