On Sun, Apr 19, 2015 at 10:33:48PM +0100, Al Viro wrote: > On Sun, Apr 19, 2015 at 02:57:07PM -0600, Andreas Dilger wrote: > > > I'd be happy if symlink recursion was removed completely, but so far the > > added symlink recursion limit hasn't been a problem for Lustre users. > > Well, it's gone in my tree; I've just pushed the current queue to > vfs.git#link_path_walk. Right now I'm looking at the unholy mess > gcc does to stack footprint with inlining - the last commit in there > is a result of exactly that. Inlines in there really need tuning ;-/ FWIW, right now in my tree the maximal stack footprint of call chains through fs/namei.c (amd64, my test config, including aushit) is 1408 bytes. Goes via rename() -> renameat2() -> user_path_parent() -> filename_lookup() -> path_lookupa() -> path_init() or follow_link() -> link_path_walk() -> walk_component() -> lookup_fast() -> follow_managed(). And that does *not* depend upon the depth of symlink nesting. The maximal depth when calling any methods present in lustre is 1328; similar path, except that its tail goes like walk_component() -> __lookup_hash() -> lookup_dcache() -> ->d_revalidate(). Again, independent from the symlink nesting depth. ->lookup() calls are at 1296 maximum, similar call chain, for ->permission() it's 1152, for ->follow_link() - 1088. For mainline it's _much_ worse. Maximal depth on the same config is 2986 bytes (with 8 levels of nesting) and each level costs 208 bytes. ->d_revalidate() is at 2880; for lustre it would be reduced a bit (again, 208 per level), but if you have any symlinks at all, you will end up deeper than in non-recursive variant. And frankly, the most scary thing in there isn't lustre-related - it's NFS4 (and AFS, etc.), where ->d_automount() might get called on _that_ depth. With quite a bit of stack footprint of its own - we are doing NFS referral handling. With almost 3Kb of stack already eaten up. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
