lib/stackdepot: Update stackdepot code to v6.8

JIRA: https://issues.redhat.com/browse/RHEL-28060
MR: !3823 (merged)

KASAN in the debug kernel will track all memory allocations including the stack traces of the allocators and saving them using stackdepot. It is thus the largest user of stackdepot. After running a variety of different workloads, it is possible that the number of stack traces saved in stackdepot or the memory used exceeds the predefined limits of stackdepot leading to various problems including system hang as shown in the Jira issue.

In this particular Jira issue, it is a s390x VM with 8G of memmory running debug kernel with kmemleak on. This amount of memory is probably not enough for such a configuration.

This MR rebases the stackdepot code to v6.8 with some associated kmemleak and KASAN commits to improve the situation which hopefully will prevent the problem mentioned in the Jira.

The improvements include:

1. Commit 56a61617dd22 ("mm: use stack_depot for recording kmemleak's backtrace") which will reduce the size of kmemleak_object by 128 bytes and hence reduce overall memory consumption with kmemleak on.
2. Various cleanup patches for the stackdepot code.
3. Commit a914d8d6cf20 ("lib/stackdepot: add printk_deferred_enter/exit guards") should prevent a lockdep splat in case a warning message is printed.
4. Commit c2a292545cd4 ("stackdepot: add stats counters exported via debugfs") will help clarify the current state of the stackdepot.

The stackdepot stats on a 2-socket system after an all core parallel kernel build on a patched RHEL kernel were:

pools: 565
refcounted_allocations: 0
refcounted_frees: 0
refcounted_in_use: 0
freelist_size: 0
persistent_count: 42663
persistent_bytes: 9178112

Signed-off-by: Waiman Long longman@redhat.com