From owner-freebsd-fs@FreeBSD.ORG Wed Nov 26 10:35:25 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDE6D16A4CE for ; Wed, 26 Nov 2003 10:35:25 -0800 (PST) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85E1043FB1 for ; Wed, 26 Nov 2003 10:35:24 -0800 (PST) (envelope-from ezk@fsl.cs.sunysb.edu) Received: from agora.fsl.cs.sunysb.edu (IDENT:aU2y3hMo8H4hncdHVTSY7dwMiY1HEzym@agora.fsl.cs.sunysb.edu [130.245.126.12])hAQIYuHn017875; Wed, 26 Nov 2003 13:34:56 -0500 Received: from agora.fsl.cs.sunysb.edu (IDENT:aDFs0EZBvK52o3HkWz/NHRiWiX5FjqCp@localhost.localdomain [127.0.0.1]) hAQIZ8g9002674; Wed, 26 Nov 2003 13:35:08 -0500 Received: (from ezk@localhost) by agora.fsl.cs.sunysb.edu (8.12.8/8.12.8/Submit) id hAQIZ8E0002670; Wed, 26 Nov 2003 13:35:08 -0500 Date: Wed, 26 Nov 2003 13:35:08 -0500 Message-Id: <200311261835.hAQIZ8E0002670@agora.fsl.cs.sunysb.edu> From: Erez Zadok To: Ian Dowse In-reply-to: Your message of "Wed, 26 Nov 2003 10:13:39 GMT." <200311261013.aa21508@salmon.maths.tcd.ie> X-MailKey: Erez_Zadok cc: amd-dev@cs.columbia.edu cc: Erez Zadok cc: fs@freebsd.org Subject: Re: vnode refcnt bug? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 18:35:26 -0000 In message <200311261013.aa21508@salmon.maths.tcd.ie>, Ian Dowse writes: > In message <200311252357.hAPNvlGs021309@agora.fsl.cs.sunysb.edu>, Erez Zadok wr > ites: > >If you have a cwd on a lower mnt pt before the mount, I'd say it makes > >_some_ sense to move it "up" to the mnt pt (root vnode) of the newly mounted > >fs. This could be very useful for, say, a login shell. > > > >I say "some" b/c I'm concerned about the possibility that some bad process > >(rm -rf) that is just started in an emoty mnt point, all of sudden is moved > >up to a vnode full of real files, and that process may happily go on to > >delete the files in the newly mounted f/s. > > > >Doing the reverse upon unmount (moving the cwd from upper to lower) sounds > >even stranger to me. Why? B/c the process used to see some files and now > >it sees none. Where did it all go? This can break applications in all > >sorts of unhappy ways. > > Whether or not checkdirs() is retained, I think it is just good > practice to undo at unmount time anything that was done when the > filesystem was mounted. An obvious case is if you accidentally mount > a file system in the wrong place or make the common mistake of > typing "mount -a" when there are NFS entries in fstab that are > already mounted. Without the unmount-time checkdirs call, this is > an operation that cannot be undone because any processes that had > a cwd of the covered vnode before the mount will lose their cwd > entirely if you unmount it. If you accidentally mount something in the wrong place, you should be able to umount it quickly thereafter; the chance that some new process comes along and "sits" on your cwd is rather rare. And if it happens, you can lsof and kill it, then umount just fine. I don't understand why would a "mount -a" re-mount existing stuff like already-mounted NFS volumes? Does it? It shouldn't IMHO. I agree w/ you that umount should undo anything that a mount did, but I think you may be allowing a mount to proceed in cases that it shouldn't have succeeded; so you first "get yourself in trouble" and then try to find a way to undo it. :-) > There were also some obscure cases involving booting frem CD and > then mounting the real root filesystem directly over /. If you > unmount it later, all processes would lose their fd_rdir references > to /, so they suddenly become chrooted into a dead vnode even though > their original root directory on the CD root still exists. OK, but "obscure cases" shouldn't IMHO change default common behavior. Make the default case the more common one, the one that will be used by most users. You went ahead and changed important behavior for a minority of users. > Anyway, I think the best solution for now is to make the checkdirs() > at unmount time conditional on the MNT_FORCE flag. This should fix > amd's EBUSY detection while still making it possible to fully undo > the effects of a mount operation. The change is fairly trivial, so > I'll see if I can get something committed before 5.2 is released. Thanks. That'd help. I would also hope that the existing cwd-migrating behavior will become the one that someone has to trigger using MNT_FORCE; that is, please make the default behavior be the old behavior (EBUSY and such). Anyone who really wants the new behavior should use MNT_FORCE (I assume there's a flag for it in umount(8) also.) > Ian Cheers, Erez.