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

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]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux