mm/slub: use stackdepot to save stack trace in objects-fix
Paul reports [1] lockdep splat HARDIRQ-safe -> HARDIRQ-unsafe lock order
detected. Kernel test robot reports [2]
BUG:sleeping_function_called_from_invalid_context_at_mm/page_alloc.c
The stack trace might be saved from contexts where we can't block so GFP_KERNEL
is unsafe. So use GFP_NOWAIT. Under memory pressure we might thus fail to save
some new unique stack, but that should be extremely rare.
[1] https://lore.kernel.org/linux-mm/
20210515204622.GA2672367@paulmck-ThinkPad-P17-Gen-1/
[2] https://lore.kernel.org/linux-mm/
20210516144152.GA25903@xsang-OptiPlex-9020/
Link: https://lkml.kernel.org/r/20210516195150.26740-1-vbabka@suse.cz
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Paul E. McKenney <paulmck@kernel.org>
Tested-by: Paul E. McKenney <paulmck@kernel.org>
Reported-by: kernel test robot <oliver.sang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>