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