Emmanuel Dreyfus <m...@netbsd.org> 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. 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 m...@netbsd.org
