From mboxrd@z Thu Jan 1 00:00:00 1970 From: raven@themaw.net Subject: Re: [RFC][PATCH 1/8] namespace: use global namespace semaphore Date: Sat, 4 Jun 2005 15:13:07 +0800 (WST) Message-ID: References: <429BD8B7.7070906@waychison.com> <429C88F9.6010200@waychison.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: mike@waychison.com, linux-fsdevel@vger.kernel.org, jamie@shareable.org, viro@parcelfarce.linux.theplanet.co.uk Return-path: Received: from wombat.indigo.net.au ([202.0.185.19]:63759 "EHLO wombat.indigo.net.au") by vger.kernel.org with ESMTP id S261278AbVFDHW4 (ORCPT ); Sat, 4 Jun 2005 03:22:56 -0400 To: Miklos Szeredi In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sat, 4 Jun 2005, Miklos Szeredi wrote: > > What interface? > > > > I'm not aware of any clearly defined API for access to in kernel functions > > for the VFS except for the various operations methods. Unfortuneatly, any > > struct that is passed to them should be largely imutable as well. Which > > ultimeatly covers the structs we are talking about here. > > You are right that it's not an explicitly defined API. However the > only _truly_ exported part of the mount api is mntget/mntput. You'll > notice, that only closely related code (path lookup, dentry cache) > will ever touch anything in struct vfsmount, and even those only in a > very few places. > > So struct vfsmount is _not_ part of the API, and no unrelated code (in > or out of the kernel) should touch any part of it. > > > All I see is people taking the oppertunity to stop exporting functions > > without consideration to what should be considered part of an API. > > > > Some companies do this really well to foster development. > > And generally using things which are not really part of an API just > results in messy and buggy code. So even if it makes development > easier, it's not worth it on the long run. OK. Sorry to go on about this but it's is just my little hobby horse. > > > Yes. That would be the case except there's a reference held to the > > vfsmount in the struct path prior to point at which follow_link is called, > > which I don't think can be obtained. > > > > In any case I'll find a way to work around it. > > I don't see why you'd need to work around anything. Following pseudo > code should work perfectly fine: > > int autofs_follow_link(struct dentry *dentry, struct nameidata *nd) > { > if (!is_mount_in_progress(dentry)) > send_trigger_to_userspace(dentry) > > wait_event(mountpoint_waitq(dentry), !is_mount_in_progress(dentry)); > while(follow_down(&nd->mnt, &nd->dentry)); > return 0; > } Indeed, that's pretty much what I have. And yes I partially missed (ignored) the fact that the follow down should do the trick because I believe that there is a follow_down (follow_mount actually) that will cause reference to a vfsmount (not accessible in follow_link) prior to the follow_link call that, at least in one case, is not put. I believe this is held in a struct path (next) local variable. For a normal link nd->mnt and next.mnt would be the same. But maybe I'm mistaken. This is what I mean when I say there appears to be an assumption that a mount is not followed immediately before the follow_link call in link_path_walk. Ian