]> git.proxmox.com Git - mirror_ubuntu-kernels.git/commit
Revert "mm/slub: use stackdepot to save stack trace in objects"
authorLinus Torvalds <torvalds@linux-foundation.org>
Sat, 17 Jul 2021 20:27:00 +0000 (13:27 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Sat, 17 Jul 2021 20:27:00 +0000 (13:27 -0700)
commitae14c63a9f20d49dacfb6f3fa3fb11b3b4eb11bf
tree15f12fd577f83f2d83983320f36b0a6405e9bd5e
parent5d766d55d163a60b709317b15db6c8bb02bf54e4
Revert "mm/slub: use stackdepot to save stack trace in objects"

This reverts commit 788691464c29455346dc613a3b43c2fb9e5757a4.

It's not clear why, but it causes unexplained problems in entirely
unrelated xfs code.  The most likely explanation is some slab
corruption, possibly triggered due to CONFIG_SLUB_DEBUG_ON.  See [1].

It ends up having a few other problems too, like build errors on
arch/arc, and Geert reporting it using much more memory on m68k [3] (it
probably does so elsewhere too, but it is probably just more noticeable
on m68k).

The architecture issues (both build and memory use) are likely just
because this change effectively force-enabled STACKDEPOT (along with a
very bad default value for the stackdepot hash size).  But together with
the xfs issue, this all smells like "this commit was not ready" to me.

Link: https://lore.kernel.org/linux-xfs/YPE3l82acwgI2OiV@infradead.org/
Link: https://lore.kernel.org/lkml/202107150600.LkGNb4Vb-lkp@intel.com/
Link: https://lore.kernel.org/lkml/CAMuHMdW=eoVzM1Re5FVoEN87nKfiLmM2+Ah7eNu2KXEhCvbZyA@mail.gmail.com/
Reported-by: Christoph Hellwig <hch@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
init/Kconfig
mm/slub.c