On Fri Jul 20 2007 at 12:25:00 +0000, tron@zhadum.org.uk wrote:
> #15 0xc032918e in getcwd_common (lvp=0xd38266e4, rvp=0xccaf1cc4,
>     bpp=0xcff91aac, bufp=0xc33bb800 "", limit=512, flags=0, l=0xcdb9da74)
>     at /usr/src/sys/kern/vfs_getcwd.c:375
> #16 0xc0220035 in procfs_readlink (v=0xcff91acc)
>     at /usr/src/sys/miscfs/procfs/procfs_vnops.c:1457
> #17 0xc0338ccb in VOP_READLINK (vp=0xd59e7304, uio=0xcff91b20, cred=0xcd9c16b0)
>     at /usr/src/sys/kern/vnode_if.c:1098
> #18 0xc032b2a4 in namei (ndp=0xcff91bd8) at /usr/src/sys/kern/vfs_lookup.c:396

The problem is calling getcwd() from a VOP.  You cannot be sure you don't
have a vnode locked on the path from the node you are calling getcwd()
from to the root.  Especially note that since your call to readlink comes
from namei(), you can't even unlock-relock, since the namei() might have
the directory vnode locked, and you can't access that from the VOP.

With the current state of things, it is trivial for any user to panic
a system with procfs mounted.

There are probably several possibilities for a kludge, but "simply"
getting rid of getcwd() calls in vops might be the best solution.

-- 
Antti Kantee <pooka@iki.fi>                     Of course he runs NetBSD
http://www.iki.fi/pooka/                          http://www.NetBSD.org/
    "la qualité la plus indispensable du cuisinier est l'exactitude"