On 7/16/21 3:37 PM, Vlastimil Babka wrote: > On 7/16/21 10:12 PM, Linus Torvalds wrote: >> On Fri, Jul 16, 2021 at 12:39 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: >>> >>> This somewhat unexpectedly causes a crash when running the xfs/433 test >>> in xfstests for me. Reverting the commit fixes the problem: >> >> I don't see why that would be the case, but I'm inclined to revert >> that commit for another reason: the code doesn't seem to match the >> description of the commit. >> >> It used to be that CONFIG_SLUB_DEBUG was a config option that was >> harmless and that defaulted to 'y' because there was little downside. >> In fact, it's not just "default y", it doesn't even *ask* the user >> unless CONFIG_EXPERT is on. Because it was fairly harmless. And then >> SLOB_DEBUG_ON was that "do you actually want this code _enabled_". >> >> But now it basically force-enables that STACKDEPOT support too, and >> then instead of having an _optional_ CONFIG_STACKTRACE, you basically >> have that as being forced on you whether you want active debugging or >> not. >> >> Maybe that >> >> select STACKDEPOT if STACKTRACE_SUPPORT >> >> should have been >> >> select STACKDEPOT if STACKTRACE > > I recall we tried that and run into KConfig recursive dependency hell as > "config STACKDEPOT" does "select STACKTRACE", and after some attempts > ended up with the above. > >> because i\t used to be that CONFIG_STACKTRACE was somewhat unusual, >> and only enabled for special debug cases (admittedly "CONFIG_TRACING" >> likely meant that it was fairly widely enabled). >> >> In contrast, STACKTRACE_SUPPORT is basically "this architecture supports it". >> >> So now it seems STACKDEPOT is enabled basically unconditionally. > > It seemed rather harmless as it was just a bit of extra code. But it's > true Geert reports [1] unexpected memory usage which I would have only > expected if actual stacks started to be collected. So I guess we'll have > to look into that. > > [1] > https://lore.kernel.org/lkml/CAMuHMdW=eoVzM1Re5FVoEN87nKfiLmM2+Ah7eNu2KXEhCvbZyA@xxxxxxxxxxxxxx/ > >> So I really don't see why it would cause that xfs issue, but I think >> there are multiple reasons to just go "Hmm" on that commit. >> >> Comments? >> >> Linus >> > There is also the matter of lib/stackdepot.c build errors on ARCH=arc: https://lore.kernel.org/lkml/202107150600.LkGNb4Vb-lkp@xxxxxxxxx/ -- ~Randy
