linux-kernel - Re: [RFC PATCH] file as directory

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]

Message-Id: <E1HqqTC-00023W-00@dorka.pomaz.szeredi.hu>
Date:	Wed, 23 May 2007 15:01:38 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	viro@....linux.org.uk
CC:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org
Subject: Re: [RFC PATCH] file as directory

> On Wed, May 23, 2007 at 12:39:25PM +0100, Al Viro wrote:
> > Then I do not understand what this mechanism could be used for, other
> > than an odd way to twist POSIX behaviour and see how much of the userland
> > would survive that.  Certainly not useful for your "look into tarball
> > as a tree", unless you seriously want to scan the entire damn fs for
> > tarballs at mount time and set up a superblock for each.  And for per-file
> > extended attributes/forks/whatever-you-call-that-abomination it also
> > obviously doesn't help, since you lose them for directories.

Someone might think of a way to make those work with directories.
Invisible directory entries, anyone?  </me ducks>

> > IOW, what uses do you have in mind?  Complete scenario, please...
> 
> Ah... After rereading the thread you've mentioned in the very beginning,
> I think I understand what you are driving at.  However, in that case
> 	* I really don't see why bother with returning vfsmount at all.
> dentry alone is enough to create a new vfsmount, all in fs/namei.c.
> 	* the lifetime rules look fscking scary.  You call that ->enter()
> on nearly every damn lookup.  OK, so you'll recreate equivalent vfsmount,
> but...  That's a lot of allocations/freeing.  Can we do some caching and
> deal with it on memory pressure?

Hmm.

> 	* invalidation on unlink is still an open problem.
> 	* locking in final mntput() doesn't look nice; we probably need
> a new refcounting scheme for vfsmounts to make that work.  I have a variant
> that might work here (and make life much easier for expiry logics in
> automount/shared trees, which is what it had been initially proposed for),

Which variant?  We had that "detached subtrees" thing, is that it?

> but it still doesn't kill the need to deal with invalidation.  And
> yes, NFS still needs it (and so do all network filesystems, really).
> The question of caching is related to that.

So what's so special about invalidation?  Why not just treat
dir-on-file mounts the same as any other ref on the dentry?

Miklos
-
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/