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
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.
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
