linux-kernel - Re: [PATCH 1/4] VFS: Add a VFS helper function vfs_remote_path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 31 Mar 2009 19:38:42 -0400
From:	Trond Myklebust <Trond.Myklebust@...app.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk,
	hch@...radead.org
Subject: Re: [PATCH 1/4] VFS: Add a VFS helper function
 vfs_remote_path_lookup()

On Tue, 2009-03-31 at 15:43 -0700, Linus Torvalds wrote:
> 
> On Tue, 31 Mar 2009, Trond Myklebust wrote:
> > 
> > No. The main purpose is to able to look up and walk down an NFSv4 mount
> > path, which is a path on the _server_'s file/directory namespace.
> 
> Sure, but that's not the "swizzle" part.
> 
> If it was just abotu the namespace part, then you'd just do one namespace 
> per server, and be done with it.
> 
> So if you split that function up into a sepate
>  - allocate namespace for nfsd
>  - free nfsd namespace
>  - do the lookup
> 
> then really _all_ the extraneous code comes just from that "playing games 
> with it" swizzling part.

Fair enough.

My main technical problem with the namespace per server is knowing when
it is safe to release it. AFAICS, you want to cache the per-server
namespace if there are mount points on "public" namespaces that
reference that server, but release it if the only remaining mount points
are the ones on the per-server namespace itself.

> > > And I think it's positively _wrong_ to have a function that creates and 
> > > destroys the whole "struct fs_struct" and a namespace for just one call. 
> > > Even if you don't think it's at all performance-critical, the interface is 
> > > too damn ugly. Have separate "create/destroy context" functions, so that 
> > > you _can_ do it just once, and have multiple calls in between.
> > 
> > That can probably be done, but the main reason for having the namespace
> > was to be able, once the sys_mount() is complete, to garbage collect and
> > get rid of those autogenerated mount points that are not user visible.
> 
> So there is never any reason to do that nfsd-specific pathwalk at 
> run-time? There are no "server pwd" requests that clients can do?

NFSv4 does theoretically support the idea of volatile filehandles. If
so, and the server were to declare that your mount point's filehandle
has expired, then your only way of recovering would be to look up that
mount path again. (We might perhaps implement client support for that
some day if somebody discovers a good enough reason).

However, if your mount point filehandle has expired, then chances are
that you'll probably have to look up all the filehandles in the mount
path again too, so why should you cache all that information?

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/