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.
