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()".
--
