The kernel warning "%s (%d) used greatest stack depth: %lu bytes left\n", provided by kernel/exit.c (split across 2 lines, after the colon, in the source code) is perhaps misleading users into thinking that something is wrong with their system (based on Google results and my own personal experience :). Might it be preferable to tweak the message a bit and use something like "%s (%d) has used the greatest stack depth so far: %lu bytes left\n"? This isn't such a big deal if the user has intentionally set CONFIG_DEBUG_STACK_USAGE, but in at least some distros (mine is Gentoo), the option is turned on by default (specifically, in 3.12.21-gentoo-r1). The fact that the messages will, by design, indicate fewer and fewer "bytes left" over time makes the warning especially scary looking. Apologies for not knowing where to put this bug; someone more knowledgeable can reclassify it (please). Also, I've submitted this under the kernel version (3.12.21-r1) that I am using, but this issue can surely be found in many/most other 3.x versions (forum posts about this message go back at least to 2007). Again, feel free to change this info.
Come to think of it, why is this a "warning" and not a "debug" level message (or at least a "notice") in the first place? I still don't understand the exact nature of the condition being reported, but it seems to be more of a "normal but significant condition" (notice log level) than an actual "warning".
Because the kernel was compiled specifically to ask for this data If Gentoo is turning on by default then fix Gentoo
So, screw the users that could possibly be helped by the change of a few words? And again I ask, why is this a warning?
Because if you turned the debug feature on you indicated you wanted to see that data, and it is presented at a higher priority so you can just gather that data without general debug noise. This is a Gentoo problem if they are turning on kernel debugging features for general usage.
You are mistaken about this being only a Gentoo (or other downstream) problem. 1. Go to kernel.org. 2. Download the 3.12.27 tar.xz file. 3. Extract the file arch/x86/configs/x86_64_defconfig 4. grep STACK x86_64_defconfig 5. Observe the following: CONFIG_DEBUG_STACK_USAGE=y CONFIG_DEBUG_STACKOVERFLOW=y So now what?
It appears to me that this bug was closed based, at least in part, on an incorrect assumption (see my previous comment). Therefore, I am reopening it. (Alan seemed to agree that it would, indeed, be a bug to enable this option "for general usage", and I indicated that the option seems to have been enabled by the kernel.org developers themselves. Therefore, that makes this a kernel.org bug, no?)
The kernel.org defaults are for developers not for end users (actually mostly it's "Linus build options")
(In reply to Alan from comment #7) > The kernel.org defaults are for developers not for end users (actually > mostly it's "Linus build options") Hmm. This doesn't seem right to me either (cf comment 6). Consider the following 4 methods of (initiating the process of) configuring a new kernel: 1. make menuconfig (saving with no changes) with no /usr/src/linux/.config* but with mounted /boot containing the current kernel and its config file 2. make defconfig under same conditions as #1 3. make menuconfig (saving with no changes) with no /usr/src/linux/.config* and /boot not mounted 4. make defconfig under same conditions as #3 When I did these with a fresh 3.14.14 tree (i.e., after installing Gentoo's gentoo-sources-3.14.14 package), the last 3 methods all resulted in exactly the same .config file. The first gave a different .config file (one with some options as configured in the current kernel [3.12.21-r1]). In *every* case, though, the options DEBUG_STACK_USAGE and DEBUG_STACKOVERFLOW both came out enabled (=y). (And, in every case certain Gentoo-specific options were enabled, as well, BTW.) Now, I have been told at Gentoo's Bugzilla, regarding these two options, that "these defaults come from upstream, from which we do not deviate." <https://bugs.gentoo.org/show_bug.cgi?id=521498> So I don't see where these options could have come from if not from arch/x86/configs/x86_64_defconfig (my machine's architecture is x86_64). And if that's the case, then it's not only users running make defconfig who will get these defaults (see method #3). Furthermore, since Gentoo doesn't deviate from the Kernel.org defaults, I don't see why any other distro should have to, either. Surely you're not saying that every distro needs to go in and specifically disable DEBUG_STACK_USAGE that was enabled by default by Kernel.org... IOW, I don't see how this is merely a "Gentoo problem". Or are you saying that the x86_64_defconfig file is not the source of these settings in the first place? In that case, I *really* don't understand what's going on, considering how methods 2, 3 and 4 above all resulted the same .config file. BTW... when I built my gentoo-sources-3.12.21-r1 based kernel (which originally precipitated this bug report -- I had used make menuconfig with /boot mounted, and of course had done a bit of configuring before saving), the kernel that was running (and the only kernel & config in /boot) was based on gentoo-sources-2.6.31-r10, which doesn't even *have* those two options. So, can someone please carefully explain to me why this is not a legitimate Kernel.org issue?
I am another Gentoo user, and I was confused by the message. I build my kernel this way since over 10 years. I am not a kernel developer. So, making this option a default is DEFINITELY not in the interest of a normal user. I think it is sad, that kernel.org thinks, that only developers download kernel sources. But it fits to many reports I am reading.