From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH 00/13] Support follow_link in RCU-walk. - V2 Date: Mon, 16 Mar 2015 19:14:45 +0000 Message-ID: <20150316191444.GZ29656@ZenIV.linux.org.uk> References: <20150316043602.23648.52734.stgit@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org To: NeilBrown Return-path: Received: from zeniv.linux.org.uk ([195.92.253.2]:34108 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756357AbbCPTOr (ORCPT ); Mon, 16 Mar 2015 15:14:47 -0400 Content-Disposition: inline In-Reply-To: <20150316043602.23648.52734.stgit@notabene.brown> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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...