svn commit: r212506 - head/sys/nfsclient
Robert Watson
rwatson at FreeBSD.org
Sun Sep 12 21:02:25 UTC 2010
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
More information about the svn-src-head
mailing list