Re: PR/38141 CVS commit: src/sys

[Andrew Doran <ad%NetBSD.org@localhost>]

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

From: Andrew Doran <ad%NetBSD.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: PR/38141 CVS commit: src/sys
Date: Wed, 7 May 2008 14:20:37 +0100

 On Wed, May 07, 2008 at 01:00:04PM +0000, Christos Zoulas wrote:
 > The following reply was made to PR kern/38141; it has been noted by GNATS.
 > 
 > From: christos%zoulas.com@localhost (Christos Zoulas)
 > To: gnats-bugs%NetBSD.org@localhost, ad%NetBSD.org@localhost, 
 > gnats-admin%netbsd.org@localhost, 
 >      netbsd-bugs%netbsd.org@localhost, yamt%mwd.biglobe.ne.jp@localhost
 > Cc: 
 > Subject: Re: PR/38141 CVS commit: src/sys
 > Date: Wed, 7 May 2008 08:59:19 -0400
 > 
 >  On May 7, 12:40am, yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi) 
 > wrote:
 >  -- Subject: Re: PR/38141 CVS commit: src/sys
 >  
 >  | The following reply was made to PR kern/38141; it has been noted by GNATS.
 >  | 
 >  | From: yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)
 >  | To: gnats-bugs%NetBSD.org@localhost
 >  | Cc: ad%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, 
 > netbsd-bugs%netbsd.org@localhost
 >  | Subject: Re: PR/38141 CVS commit: src/sys
 >  | Date: Wed,  7 May 2008 09:36:37 +0900 (JST)
 >  | 
 >  |  >  One effect of this change: previously if an unmount failed, we would 
 > make a
 >  |  >  half hearted attempt to back out of it gracefully, but that was 
 > unlikely to
 >  |  >  work in a lot of cases. Now while an unmount that will be aborted is 
 > in
 >  |  >  progress, new file operations within the mount will fail instead of 
 > being
 >  |  >  delayed. That is unlikely to be a problem though, because if the admin
 >  |  >  requests unmount of a file system then s(he) has made a decision to 
 > deny
 >  |  >  access to the resource.
 >  |  
 >  |  doesn't it break, say, amd(8)?
 >  
 >  amd will fail if umount on a busy filesystem succeeds.
 
 I'm guessing how amd works - haven't researched it yet - but I think the
 main problem will be new calls to VFS_ROOT() from lookup(). While an idle
 file system is being garbage collected by amd, those will fail with EBUSY.
 So there's a small window across the unmount where operations would fail
 instead of causing an automount to occur.
 
 For an unmount that's not forced, those should be easy enough to gate
 because it's OK to wait there. The deadlocks (some of which have been there
 for a long time) start happening when we cause threads already in the guts
 of the file system code to wait, because there is a tangled mess of locks.
 
 Andrew