On Tue, May 22, 2018 at 03:39:11PM +0200, Martin Pieuchot wrote: > By assuming that `f_data' is immutable, which AFAIK is true for sockets, > we can remove the KERNEL_LOCK() from the following syscalls iff files are > refcounted in an MP-safe way. > > This diff includes the EBUSY check in dup2(2) which is currently required > to avoid races with accept(2) and will later make our life easier wrt > open(2). > > It also includes the fdinsert() diff I sent earlier. > > On top of that I'm introducing a global mutex, `fhdlk', that protects > `f_count' and the implicit reference in `filehead'. > > A socket stays alive as long as its associated file has a positive > refcount. When this refcount drops, fdrop() will be called and soclose() > will free/clean `f_data'. That's the only place where `f_data' is > changed during the life of a socket. That's why it is safe to dereference > `f_data' when getsock() returned a valid & refcounted `fp'. > > Many ktrace(2) internals now need to grab the KERNEL_LOCK(), just like > ptsignal(). > > Note that for unix, routing and pfkey sockets, solock() still grabs the > KERNEL_LOCK(). So even if syscalls are marked as SY_NOLOCK that doesn't > mean they won't grab it. In fact some network functions like > ifa_ifwithaddr() below now need to grab the KERNEL_LOCK(). That's good > that means we're pushing the lock down. > > Tests? Comments?
I applied the diff, made syscalls, then built and installed a new kernel. With that, I ran into a reliable complete lockup on my x230 by starting in an xterm # make -j 3 build 2>&1 | tee -a /home/theo/buildlog and then navigating firefox to youtube and trying to start some video. Unfortunately, I don't know how to provide you with any more useful information. The machine becomes completely unresponsive, the mouse pointer is frozen, I'm unable to break into ddb, and the machine is no longer pingable.
