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

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

The following reply was made to PR kern/28448; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: YAMAMOTO Takashi <yamt%mwd.biglobe.ne.jp@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, kern-bug-people%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
pooka%NetBSD.org@localhost
Subject: Re: kern/28448 (stackable filesystems locking breakage when
        looking up DOTDOT)
Date: Sat, 3 Jan 2009 04:37:27 +0000

 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