From: Al Viro <viro@ZenIV.linux.org.uk>
To: Andreas Dilger <adilger@dilger.ca>
Cc: NeilBrown <neilb@suse.de>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Oleg Drokin <oleg.drokin@intel.com>,
Andreas Dilger <andreas.dilger@intel.com>
Subject: Re: [PATCH 02/20] STAGING/lustre: limit follow_link recursion using stack space.
Date: Mon, 20 Apr 2015 03:29:42 +0100 [thread overview]
Message-ID: <20150420020933.GI889@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20150419213348.GH889@ZenIV.linux.org.uk>
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.
next prev parent reply other threads:[~2015-04-20 2:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-23 2:37 [PATCH 00/20] Support follow_link in RCU-walk - V3 NeilBrown
2015-03-23 2:37 ` [PATCH 02/20] STAGING/lustre: limit follow_link recursion using stack space NeilBrown
2015-04-18 3:01 ` Al Viro
2015-04-19 20:57 ` Andreas Dilger
2015-04-19 21:33 ` Al Viro
2015-04-20 2:29 ` Al Viro [this message]
2015-03-23 2:37 ` [PATCH 01/20] Documentation: remove outdated information from automount-support.txt NeilBrown
2015-03-23 2:37 ` [PATCH 03/20] VFS: replace {, total_}link_count in task_struct with pointer to nameidata NeilBrown
2015-03-23 2:37 ` [PATCH 07/20] VFS: remove nameidata args from ->follow_link NeilBrown
2015-03-23 2:37 ` [PATCH 04/20] ovl: rearrange ovl_follow_link to it doesn't need to call ->put_link NeilBrown
2015-03-23 2:37 ` [PATCH 05/20] VFS: replace nameidata arg to ->put_link with a char* NeilBrown
2015-03-23 2:37 ` [PATCH 10/20] security: make inode_follow_link RCU-walk aware NeilBrown
2015-03-23 2:37 ` [PATCH 09/20] security/selinux: pass 'flags' arg to avc_audit() and avc_has_perm_flags() NeilBrown
2015-03-23 2:37 ` [PATCH 06/20] SECURITY: remove nameidata arg from inode_follow_link NeilBrown
2015-03-23 2:37 ` [PATCH 08/20] VFS: make all ->follow_link handlers aware for LOOKUP_RCU NeilBrown
2015-03-23 2:37 ` [PATCH 11/20] VFS/namei: use terminate_walk when symlink lookup fails NeilBrown
2015-03-23 2:37 ` [PATCH 12/20] VFS/namei: new flag to support RCU symlinks: LOOKUP_LINK_RCU NeilBrown
2015-03-23 2:37 ` [PATCH 15/20] VFS/namei: enhance follow_link to support RCU-walk NeilBrown
2015-03-23 2:37 ` [PATCH 19/20] XFS: allow follow_link to often succeed in RCU-walk NeilBrown
2015-03-23 2:37 ` [PATCH 18/20] xfs: use RCU to free 'struct xfs_mount' NeilBrown
2015-03-23 2:37 ` [PATCH 16/20] VFS/namei: enable RCU-walk when following symlinks NeilBrown
2015-03-23 2:37 ` [PATCH 13/20] VFS/namei: abort RCU-walk on symlink if atime needs updating NeilBrown
2015-03-23 2:37 ` [PATCH 17/20] VFS/namei: handle LOOKUP_RCU in page_follow_link_light NeilBrown
2015-03-23 2:37 ` [PATCH 14/20] VFS/namei: add 'inode' arg to put_link() NeilBrown
2015-04-17 16:25 ` Al Viro
2015-04-17 19:09 ` Al Viro
2015-04-18 8:09 ` Al Viro
2015-03-23 2:37 ` [PATCH 20/20] NFS: support LOOKUP_RCU in nfs_follow_link NeilBrown
2015-03-25 23:23 ` [PATCH 00/20] Support follow_link in RCU-walk - V3 NeilBrown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150420020933.GI889@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=adilger@dilger.ca \
--cc=andreas.dilger@intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
--cc=oleg.drokin@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox