tech-kern archive

[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 <> 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

Juergen Hannken-Illjes - - TU Braunschweig 

Home | Main Index | Thread Index | Old Index