[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: PUFFS deadlock
On Feb 3, 2012, at 5:45 PM, Emmanuel Dreyfus wrote:
> Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:
>> What about adding a timeout in struct puffs_msgpark and use it for
>> inactive operations? Returning EAGAIN from puffs_vnop_inactive seems an
>> easy way to work around this deadlock.
> I reply to myself. This will probably break many things since
> VOP_INACTIVE return code is not checked, neither in vrelel() nor in
> As I understand, the problem will occur when:
> 1) a PUFFS filesystem does a namei(), most likely on a path component
> leading to its filesystem mont point. It sleeps for the parent vnode
> 2) another process which locks the desired vnode goes the
> path on a vnode in the PUFFS filesystem.
So this is on 5.x ?
For -current the getnewvnode()->getcleanvnode() path has been replaced
with a cleaner thread so getnewvnode() always gets a new vnode. This was
done to break deadlocks like this one (most time with layered fs involved).
> 3) PUFFS is sleeping in kernel and will never service the VOP_INACTIVE.
> The vnode remains locked forever. Since it is very likely to be the root
> vnode, all processes doing a VOP_LOOKUP end up sleeping for the root
> vnode lock.
> How can this be fixed?
> Emmanuel Dreyfus
Juergen Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig
Main Index |
Thread Index |