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?
Robert
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
