From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753501AbbDTC3u (ORCPT ); Sun, 19 Apr 2015 22:29:50 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:58004 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751986AbbDTC3s (ORCPT ); Sun, 19 Apr 2015 22:29:48 -0400 Date: Mon, 20 Apr 2015 03:29:42 +0100 From: Al Viro To: Andreas Dilger Cc: NeilBrown , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Oleg Drokin , Andreas Dilger Subject: Re: [PATCH 02/20] STAGING/lustre: limit follow_link recursion using stack space. Message-ID: <20150420020933.GI889@ZenIV.linux.org.uk> References: <20150323023258.8161.32467.stgit@notabene.brown> <20150323023738.8161.97062.stgit@notabene.brown> <20150418030128.GF889@ZenIV.linux.org.uk> <20150419213348.GH889@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150419213348.GH889@ZenIV.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.