From: Al Viro <viro@ZenIV.linux.org.uk>
To: NeilBrown <neilb@suse.de>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/13] Support follow_link in RCU-walk. - V2
Date: Mon, 16 Mar 2015 19:14:45 +0000 [thread overview]
Message-ID: <20150316191444.GZ29656@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20150316043602.23648.52734.stgit@notabene.brown>
On Mon, Mar 16, 2015 at 03:43:19PM +1100, NeilBrown wrote:
> Hi Al,
> I believe this series addresses all your concerns about
> my first attempt.
> The first patch results in nameidata being almost completely
> localized to namei.c :-) It also highlights out-of-date
> documentation in automount-support.txt :-(
>
> It also exposes (and removes) some ... interesting code in lustre.
> I'm not sure how safe it is to remove that.... I didn't think
> recursive symlinks used extra stack.
Recursive nested symlinks *do* use extra stack; it's not in fs code, though.
make fs/namei.s and check link_path_walk; AFAICS, on amd64 it's 192 bytes per
level, on sparc64 - 256, sparc32 and ppc32 - 144, ppc64 - obscenely fat 336...
It's more that lustre is an extreme stack hog; call its methods on slightly
deeper stack and you are screwed. I don't _know_ if that's pure paranoia -
might very well be. OTOH, it might be not paranoid enough. OTTH, if it
manages to survive 5 levels on 4K stack, it ought to survive 8 levels on 8K
one; if 3 times the footprint of link_path_walk pushes the total by more 4K,
there's no way in hell to fit 5 times that footprint into 4K stack, nevermind
the rest of call chain...
prev parent reply other threads:[~2015-03-16 19:14 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-16 4:43 [PATCH 00/13] Support follow_link in RCU-walk. - V2 NeilBrown
2015-03-16 4:43 ` [PATCH 02/13] VFS: make all ->follow_link handlers aware for LOOKUP_RCU NeilBrown
2015-03-16 4:43 ` [PATCH 03/13] VFS: remove nameidata args from ->follow_link and ->put_link NeilBrown
2015-03-16 20:47 ` Al Viro
2015-03-16 4:43 ` [PATCH 01/13] VFS: replace {, total_}link_count in task_struct with pointer to nameidata NeilBrown
2015-03-16 19:46 ` Al Viro
2015-03-16 4:43 ` [PATCH 04/13] security/selinux: check for LOOKUP_RCU in _follow_link NeilBrown
2015-03-16 21:00 ` Al Viro
2015-03-20 4:39 ` NeilBrown
2015-03-20 5:12 ` Al Viro
2015-03-16 4:43 ` [PATCH 05/13] VFS/namei: use terminate_walk when symlink lookup fails NeilBrown
2015-03-16 4:43 ` [PATCH 08/13] VFS/namei: enhance follow_link to support RCU-walk NeilBrown
2015-03-16 4:43 ` [PATCH 06/13] VFS/namei: new flag to support RCU symlinks: LOOKUP_LINK_RCU NeilBrown
2015-03-16 22:33 ` Al Viro
2015-03-17 0:59 ` Al Viro
2015-03-16 4:43 ` [PATCH 12/13] XFS: allow follow_link to often succeed in RCU-walk NeilBrown
2015-03-16 22:37 ` Al Viro
2015-03-16 4:43 ` [PATCH 09/13] VFS/namei: enable RCU-walk when following symlinks NeilBrown
2015-03-16 22:44 ` Al Viro
2015-03-16 4:43 ` [PATCH 13/13] NFS: support LOOKUP_RCU in nfs_follow_link NeilBrown
2015-03-16 4:43 ` [PATCH 10/13] VFS/namei: handle LOOKUP_RCU in page_follow_link_light NeilBrown
2015-03-16 22:50 ` Al Viro
2015-03-19 22:38 ` NeilBrown
2015-03-19 23:46 ` Al Viro
2015-03-16 4:43 ` [PATCH 11/13] xfs: use RCU to free 'struct xfs_mount' NeilBrown
2015-03-16 4:43 ` [PATCH 07/13] VFS/namei: abort RCU-walk on symlink if atime needs updating NeilBrown
2015-03-16 19:14 ` Al Viro [this message]
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=20150316191444.GZ29656@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=neilb@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.