Re: kern/28448 (stackable filesystems locking breakage when looking up DOTDOT)

[David Holland <dholland-bugs%netbsd.org@localhost>]

On Sat, Jan 03, 2009 at 01:11:59PM +0900, YAMAMOTO Takashi wrote:
 > > 2) the lower layer does not export a lock pointer, in which case the
 > >    relock dance in the lower layer will not use the upper layer's
 > >    locks
 > 
 > this PR was about 2).
 > it can deadlock between the parent and child directories
 > in the upper layer due to the lack of dotdot relock dances in
 > the upper layer.  the relock dance in the lower layer doesn't
 > make sense because it's done keeping the upper layer vnode locked.

So (to clarify as much as possible) the case is:

   a. locks are not shared between the upper and lower layers
   b. we try to lookup .. on an upper layer directory UD
   c. vfs locks the directory, which locks both UD and the lower-layer
      directory LD corresponding to UD
   d. vfs calls VOP_LOOKUP, which goes to layer_lookup, which goes to
      the lower fs
   e. the lookup op on the lower fs unlocks LD and locks LD's parent,
      then returns LD's parent
   f. layer_lookup gets LD's parent back and digs out the
      corresponding upper vnode with layer_node_create
   g. layer_node_create then locks vnode without first unlocking UD
   h. this violates the locking order, because UD's parent is locked
      after UD.

Do we have any layered fses where both c. and d. happen? It seems to
me, based on my perhaps too vague understanding of how the layering
system works, that if you don't share locks you can't expect to share
the fs namespace, meaning you can't expect to use the default
layer_lookup. I suspect this is not the only problem that'll show up
if someone tries.

If that's supposed to be legal, then it's a problem, yes. Nice catch :-)

(although note that I'm planning to abolish the dotdot-dance)

-- 
David A. Holland
dholland%netbsd.org@localhost