| 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
| ||
|
Date: Mon, 18 May 2015 04:42:49 +0100 From: Al Viro <viro@...IV.linux.org.uk> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: NeilBrown <neilb@...e.de>, Andreas Dilger <adilger@...ger.ca>, Dave Chinner <david@...morbit.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, Christoph Hellwig <hch@...radead.org> Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks On Sun, May 17, 2015 at 07:56:26PM -0700, Linus Torvalds wrote: > > So for Al's example of revalidating multiple components at once, once the VFS > > gets to a point in the path where d_revalidate says "I need more time", > > the VFS just passes the rest of the path to the filesystem. > > That's bullshit,. for a very simple and basic reason: "the rest of the > path" is not necessarily at all for your filesystem! > > Really. There might be mount-points, there might be symlinks, there > might be tons of stuff like that. "Rest of the path" makes no sense, obviously. "More of the path" (and _not_ as a string, TYVM - we have those components in ->d_name.name of dentries we want revalidated, complete with hashes, so WTF redo that?) is fine, though, because the caller knows exactly where the mountpoints are, so we know how far we can go. > Now, this is why I said we can do a "hint" style thing. Part of that > "hint" issue is very very much that it has no semantic meaning. You > can't screw it up, because if it turns out that the path component > we're looking up is a symlink and we actually end up in some other > filesystem, if you end up looking up the hint part, it just would > never actually get used. For revalidate "this used to be a symlink, now it's not" or vice versa means simply "it's gone stale". Which is fine - again, the caller knows where in that chain the symlinks are (and they obviously terminate the chain to be revalidated). Anyway, it's a side issue; we _can_ use the capability to do multi-component lookups and with link_path_walk()-related logics getting untangled, we might be able to do just that without messing the code up. It's very clearly not a 4.2 fodder, though, and I'm not sure how high priority it is for 4.3, simply because making the exclusion between lookups weaker seems to be of more general interest. And those two will definitely be stepping on the same area, so it probably makes more sense to sort the parallel lookups out first. _IF_ we manage to get that by 4.3-rc<early>, sure, continuation into multicomponent lookups would start looking as 4.3 material. Hell knows - stranger things have happened... What we really need is a coherent documentation on the whole pathname-related machinery; I've some preliminary bits and pieces written, but it'll take more work. Hopefully I'll have something postable in a week or less... Right now I can think of 4 or 5 people familiar with the area, myself included. And we need more - it shouldn't be a fucking black magic, since fs folks really ought to understand what's going on there. The thing is, under the assorted layers of cruft it's simpler than e.g. VMA handling... -- 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/
Powered by blists - more mailing lists