Re: PUFFS deadlock

["J. Hannken-Illjes" <hannken%eis.cs.tu-bs.de@localhost>]

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
> vclean(). 
> 
> 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
> lock.
> 
> 2) another process which locks the desired vnode goes the
> getnewvnode/getcleanvnode/vclean/VOP_INACTIVE
> 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
> http://hcpnet.free.fr/pubz
> manu%netbsd.org@localhost

--
Juergen Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig 
(Germany)