svn commit: r212506 - head/sys/nfsclient
Kostik Belousov
kostikbel at gmail.com
Sun Sep 12 20:53:15 UTC 2010
On Sun, Sep 12, 2010 at 09:41:46PM +0100, Robert Watson wrote:
>
> On Sun, 12 Sep 2010, Konstantin Belousov wrote:
>
> > Do not fork nfsiod directly from the vop methods. This causes LORs between
> > vnode lock and several locks needed during fork, like fd lock.
> >
> > Instead, schedule the task to be executed in the taskqueue context. We
> > still waiting for the fork to finish, but the context of the thread
> > executing the task does not make real LORs with our vnode lock.
>
> Does this actually functionally improve things, or is all this complexity
> about suppressing the lock order reversal? If we're waiting synchronously
> for the other thread to launch from the task queue, then the lock order
> reversal still exists, it's just not visible to WITNESS... If we had a
> static analysis tool that could run on lock and sleep/wakeup traces, it
> would still show a deadlock opportunity.
As I said in commit message, the deadlock should be fixed, because the
taskq thread is executed in the kernel process that should even not have
file descriptors at all.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20100912/df19217c/attachment.pgp
More information about the svn-src-head
mailing list