svn commit: r193165 - head/sys/compat/linux

Kostik Belousov kostikbel at gmail.com
Sun May 31 12:54:09 UTC 2009


On Sun, May 31, 2009 at 03:45:55PM +0300, Kostik Belousov wrote:
> On Sun, May 31, 2009 at 02:26:42PM +0200, Jilles Tjoelker wrote:
> > On Sun, May 31, 2009 at 12:04:01PM +0000, Dmitry Chagin wrote:
> > > Author: dchagin
> > > Date: Sun May 31 12:04:01 2009
> > > New Revision: 193165
> > > URL: http://svn.freebsd.org/changeset/base/193165
> > 
> > > Log:
> > >   Move new socket flags handling into a separate function as Linux
> > >   introduced more syscalls which uses these flags.
> > 
> > I think this does not fulfill the purpose of LINUX_SOCK_CLOEXEC exactly:
> > if another thread forks and execs at the wrong time, it may inherit the
> > socket without the CLOEXEC flag set.
> > 
> > The obvious way to fix this is to implement SOCK_CLOEXEC in the native
> > syscalls, in such a way that other threads can never see the new fd
> > without the CLOEXEC flag set.
> > 
> > That could be fairly complicated and it is a pretty rare situation,
> > however.
> 
> This is well-known issue, that is omnipresent in the linuxolator.
> Your analysis is right, but until we implement corresponding
> facilities for the native ABI, linuxolator will be in is this state.
> Whether we really need to do the work for freebsd binaries is
> debatable.
> 
> For the typical case, see linux_common_open(). 

Mostly replying to myself. The fact that your statement about race is
right actually points to the deficiency in the implementation of the
linux_execve(), as opposed to the bug in the LINUX_SOCK_CLOEXEC handling.

Complete execve(2) implementation should do single-threading for the
curproc, and singlethreading happens only when all threads except
the one doing execve cross the boundary. See call to thread_single
in kern_execve. This does not really happen for linux ABI processes,
since multithreading is implemented as multiprocessing. When (if) a
singlethreading solution will be implemented for linux ABI, exec cannot
happen between these two calls, since the thread is still in kernel not
on the single-threading boundary.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20090531/e216fc08/attachment.pgp


More information about the svn-src-head mailing list