On 7/18/21 12:29 AM, Vlastimil Babka wrote:

On 7/17/21 7:34 PM, Randy Dunlap wrote:

quoted

quoted

quoted

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@mail.gmail.com/ (local)

quoted

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@intel.com/ (local)

That's being fixed AFAIK?

https://lore.kernel.org/lkml/20210710145033.2804047-1-linux@roeck-us.net/ (local)

Ah, thanks.

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