Re: [patch 07/54] mm/slub: use stackdepot to save stack trace in objects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux