On 20/01/17(Fri) 17:16, Alexander Bluhm wrote:
> > --- sys/kern/kern_rwlock.c
> > +++ sys/kern/kern_rwlock.c
> > @@ -195,6 +195,9 @@ retry:
> > unsigned long set = o | op->wait_set;
> > int do_sleep;
> >
> > + if (panicstr)
> > + return (0);
>
On 20/01/17(Fri) 12:04, Martin Pieuchot wrote:
> Diff below enables the NET_LOCK(), again.
>
> What's new?
>
> - The lock ordering problem with fdplock() should now be fixed. It is
>also documented, fdplock() should be taken first if both locks are
>needed.
>
> - Page faults
On Fri, Jan 20, 2017 at 05:16:50PM +0100, Alexander Bluhm wrote:
> I am currently running a full regress test with this diff.
> It hangs at /usr/src/regress/lib/libpthread/socket
Tests have finished, libpthread was aborted after 1 hour, process
socket1 still lives. The machine is running a
On Fri, Jan 20, 2017 at 12:04:31PM +1000, Martin Pieuchot wrote:
> - Page faults involving NFS, or any other code path already holding the
>NET_LOCK(), have been fixed. The recursion is similar to the existing
>vnode problem, so I simply added a hack there.
It survives my nfs mmap
On 20.1.2017. 3:04, Martin Pieuchot wrote:
> Diff below enables the NET_LOCK(), again.
>
> What's new?
>
> - The lock ordering problem with fdplock() should now be fixed. It is
>also documented, fdplock() should be taken first if both locks are
>needed.
>
> - Page faults involving
Diff below enables the NET_LOCK(), again.
What's new?
- The lock ordering problem with fdplock() should now be fixed. It is
also documented, fdplock() should be taken first if both locks are
needed.
- Page faults involving NFS, or any other code path already holding the
NET_LOCK(),
