From owner-freebsd-fs Tue Aug 4 16:20:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA14386 for freebsd-fs-outgoing; Tue, 4 Aug 1998 16:20:33 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA14151; Tue, 4 Aug 1998 16:18:43 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id QAA04617; Tue, 4 Aug 1998 16:18:32 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp03.primenet.com, id smtpd004591; Tue Aug 4 16:18:28 1998 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id QAA11288; Tue, 4 Aug 1998 16:18:25 -0700 (MST) From: Terry Lambert Message-Id: <199808042318.QAA11288@usr07.primenet.com> Subject: Re: Exclusive locking for directory lookups? To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Tue, 4 Aug 1998 23:18:25 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG, core@FreeBSD.ORG In-Reply-To: <199808041758.NAA03021@khavrinen.lcs.mit.edu> from "Garrett Wollman" at Aug 4, 98 01:58:33 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Does anybody remember why plain-jane directory lookups (i.e., not > deleting or creating anything) require an exclusive lock on all the > directory vnodes along the path? It would seem to be that only shared > locks should be necessary in those cases... Because there is no flag from namei() to indicate whether the terminal path component is going to be modified or not. This is more a symptom of the way namei() is implemented; it can't support inheritance of such a flag (or inheritance of a POSIX namespace escape ("///") for the same reason. The locking is a tail-chase down the tree -- that is, the lock is one-behind (parent and child) and is not held to the root. The real question is whether the race this is protecting against still exists with a unified VM and buffer cache... in which case, the you could reexamine the need for it (for this to work, you would need my patch to have namei() to return the EEXISTS, instead of duplicating the code every place you wanted a lookup to fail if the target exists, ie: the create/rename target cases, etc. -- you need to distinguis internal vs. external error return for this case). My gut feeling is that it is still neccessary, even though the race it was intended to protect against was a VM and buffer cache coherency with multiple accesses in the "write entry" case, mostly because of the late buffer mapping. I could be wrong here, though. In any case, that would mean you would need to add a flag to indicate a terminal component lookup to VOP_LOOKUP. This is somewhat problematic, because an underlying FS is permitted to eat as many components as it wants to, according to the design. To get around this, the idea that it is the terminal component would have to be indicated by the non-existance of a "next component". To implement this approach would require pre-parsing the path into components. The easiest way to do this would be to keep a seperate "total length" in the path component buffer, and replace the path sperators with NUL, treating it as a pre-strtok'ed string. If you go this route, consider providing access macros as well, making the underlying FS advance cn_nameptr (if it consumes extra components), and in general making the structure opaque enough that we could support multiple namespaces (the current VFAT short name binding and assumption of ISO 8859-1 character set instead of Unicode is broken). The underlying VOP_LOOKUP for the "writing an entry" case would use the accessor macro to ask for the start of the next component; if it got a NULL back, it would know it was terminal, and that it needed to lock (handling the EEXISTS case in namei() lets you avoid this lock, if the lookup would succeed). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message