Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753691AbYH0Cx4 (ORCPT ); Tue, 26 Aug 2008 22:53:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752299AbYH0Cxq (ORCPT ); Tue, 26 Aug 2008 22:53:46 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:43479 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752075AbYH0Cxp (ORCPT ); Tue, 26 Aug 2008 22:53:45 -0400 Date: Tue, 26 Aug 2008 19:52:26 -0700 (PDT) From: Linus Torvalds To: Parag Warudkar cc: Adrian Bunk , Rusty Russell , "Alan D. Brunelle" , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Andrew Morton , Arjan van de Ven , Ingo Molnar , linux-embedded@vger.kernel.org Subject: Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected In-Reply-To: Message-ID: References: <20080826183051.GB10925@cs181140183.pp.htv.fi> <20080826205916.GB11734@cs181140183.pp.htv.fi> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2111 Lines: 45 On Tue, 26 Aug 2008, Parag Warudkar wrote: > > What about deep call chains? The problem with the uptake of 4K stacks > seems to be that is not reliably provable that it will work under all > circumstances. Umm. Neither is 8k stacks. Nobody "proved" anything. But yes, some subsystems have insanely deep call chains. And yes, things like the VFS recursion (for symlinks) makes that deeper yet for filesystems, although only on the lookup path. And that is exactly the kind of thing that can exacerbate the problem of the compiler artificially making for a bigger stack footprint of a function (*). For things like the VFS layer, right now we allow a nesting level of 8, I think. If I remember correctly, it was 5 historically. Part of raising that depth, though, was that we actually moved the recursive part into fs/namei.c, and the nesting stack-depth was something pretty damn small when the filesystem used "follow_link" properly and let the VFS do it for it (ie the callchain to actually look up the link could be deep, but it would not recurse back, and instead just return a pointer, so that the actual _recursive_ part was just __do_follow_link() and is just a few words on the stack). So yes, we do have some deep callchains, but they tend to be pretty well managed for _good_ code. The problems tend to be the areas with lots of indirection layers, and yeah, XFS, MD and ACPI all have those kinds of things. In an embdedded world, many of those should be a non-issue, though. Linus (*) ie the function that _is_ on the deep chain doesn't actually need much of a stack footprint at all itself, but it may call a helper function that is _not_ in the deep chain, and if it gets inlined it may give its excessive stack footprint to the deep chain - and this is _exactly_ the problem that happened with inlining "load_module()". -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/