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/18/21 12:29 AM, Vlastimil Babka wrote:
> On 7/17/21 7:34 PM, Randy Dunlap wrote:
>>>> 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/
> 
> That's being fixed AFAIK?
> 
> https://lore.kernel.org/lkml/20210710145033.2804047-1-linux@xxxxxxxxxxxx/

Ah, thanks.

> I'll try to come up with some KConfig flag set that will make it depend
> on STRACKTRACE again without recursion issues.
> 




[Index of Archives]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux