From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Waychison Subject: Re: [RFC][PATCH 1/8] namespace: use global namespace semaphore Date: Tue, 31 May 2005 11:55:37 -0400 Message-ID: <429C88F9.6010200@waychison.com> References: <429BD8B7.7070906@waychison.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Miklos Szeredi , linux-fsdevel@vger.kernel.org, jamie@shareable.org, viro@parcelfarce.linux.theplanet.co.uk Return-path: Received: from dsl081-242-086.sfo1.dsl.speakeasy.net ([64.81.242.86]:25514 "EHLO lapdance.christiehouse.net") by vger.kernel.org with ESMTP id S261919AbVEaP6G (ORCPT ); Tue, 31 May 2005 11:58:06 -0400 To: Ian Kent In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Kent wrote: > On Mon, 30 May 2005, Mike Waychison wrote: >> >> No, the removal of struct namespace shouldn't keep you from walking >> vfsmounts from modules. In fact, in Miklos' 1/8 patch, he moved >> namespace->sem to a global semaphore, which isn't needed by the end of >> the patch set. namespace->sem only ever protected the namespace->list >> field. > > But my impression was that this semaphore surrounded the mount and umount > processes. The list updates looked like they were all done when this > semaphore was held. > namespace->sem did indeed surround the mounting and unmounting processes, however it never was meant to protect the integrety of the vfsmount tree, only namespace->list. Due to the lock nesting rules of vfs, it did infact exclude any tree operations, however the proper lock to have used was always vfsmount_lock > >> If you which to walk a mounttree, you still only ever require grabbing >> vfsmount_lock and use mntget/mntput. > > > Which is not exported. > > So do you think it should be? Yes. Even better would be for a proper interface to be exported from fs/namespace.c though, so that as a module you don't care about the nitty gritty details of how the tree is held together. This is likely to get even more complicated with time as Ram's patches get more testing. > Maybe lookup_mnt shouldn't be static and should be exported instead? > lookup_mnt is the wrong operation, as it looks for a mountpoint given a vfsmount and dentry. What you need is a way to walk the tree, and I'm inclined to say that something like next_mnt is what you are looking for. > >> Overall, this means autofs4 stuff will need to be updated to reflect >> these changes, but they are minimal at best. > > > OK. But I'm not sure how I can get at this from within a module. > Right now, the quickest way is to EXPORT_SYMBOL(vfsmount_lock) and grab it instead of namespace->sem. > Perhaps something like updating the nameidata struct passed to > follow_link, similar to what you did elsewhere in your autofsng > patches, needs to be added to this lot. I'm lost to what you mean. The only place autofsng touches nameidata in the VFS is setting ->mnt to a non-stale mount before a ->follow_link. That symlinks even work without this change is almost coincidence. Mike Waychison -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCnIj5dQs4kOxk3/MRArdfAJ0Ytphl0/ly9Ds6v/WDiCTy+FBwdACfeT+r TO/HFIluXOPYZGcZUBqrr+c= =EMfY -----END PGP SIGNATURE-----