i _specifically_ objected to the uglification that this patch brings
with itself to the modified arch/x86 files (see the diff excerpt below),
in:
http://lkml.org/lkml/2008/3/19/450
i pointed out how it should be done _much cleaner_ (and much smaller -
only a single patch needed) via stack-trace, without changing a dozen
architectures, and even gave a patch to make it all easier for you:
http://lkml.org/lkml/2008/3/19/568
http://lkml.org/lkml/2008/3/21/88
in fact, a stacktrace printout is much more informative as well to
users, than a punny __builtin_return_address(0)!
but you did not reply to my objections in substance, hence i considered
the issue closed - but you apparently went ahead without addressing my
concerns (which are rather obvious to anyone doing debug code) and now
this ugly code is upstream.
If lockdep can get stacktrace samples from all around the kernel without
adding "caller" info parameters to widely used APIs, then the MM is
evidently able to do it too. _Saving_ a stacktrace is relatively fast
[printing it to the console is what is slow], and vmalloc() is an utter
slowpath anyway [and 1 million file descriptors does not count as a
fastpath].
If performance is of any concern then make it dependent on
CONFIG_DEBUG_VM or whatever debug switch in the MM - that will be
_faster_ in the default case than the current
pass-parameter-deep-down-the-arch crap you've pushed here. I dont
remember the last time i genuinely needed the allocation site of a
vmalloc().
I any case, do _NOT_ pollute any architectures with stack debugging
hacks (and that holds for future similar patches too), that's why we
wrote stacktrace. This needs to be reverted or fixed properly.
--
