svn commit: r212506 - head/sys/nfsclient

[Kostik Belousov]

On Sun, Sep 12, 2010 at 10:02:24PM +0100, Robert Watson wrote:
> 
> On Sun, 12 Sep 2010, Kostik Belousov wrote:
> 
> >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.
> 
> Ah, I think I see where my misunderstanding arose: the behavior of kernel 
> process fork is changed as a result of running in a different (specific) 
> context, and hence never acquires the file descriptor lock class?

The original code created nfsiod by forking inside the vop, that happens
to execute in the context of whatever user process that initiated the
operation. Taskqueue is executing in the intr process context, that
should not have file descriptors allocated at all.

Actually, even if the intr process had fd allocated, then it still should
not lock the table.
-------------- 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-all/attachments/20100912/907ac295/attachment.pgp