Re: [patch 07/54] mm/slub: use stackdepot to save stack trace in objects

(off-list ancestor, not in this archive)
Re: [patch 07/54] mm/slub: use stackdepot to save stack trace in objects · Christoph Hellwig <hch@infradead.org> · 2021-07-16
Re: [patch 07/54] mm/slub: use stackdepot to save stack trace in objects · Vlastimil Babka <hidden> · 2021-07-16
Re: [patch 07/54] mm/slub: use stackdepot to save stack trace in objects · Christoph Hellwig <hch@infradead.org> · 2021-07-16
Re: [patch 07/54] mm/slub: use stackdepot to save stack trace in objects · Linus Torvalds <torvalds@linux-foundation.org> · 2021-07-16
Re: [patch 07/54] mm/slub: use stackdepot to save stack trace in objects · Vlastimil Babka <hidden> · 2021-07-16
Re: [patch 07/54] mm/slub: use stackdepot to save stack trace in objects · Randy Dunlap <hidden> · 2021-07-17
Re: [patch 07/54] mm/slub: use stackdepot to save stack trace in objects · Vlastimil Babka <hidden> · 2021-07-18
Re: [patch 07/54] mm/slub: use stackdepot to save stack trace in objects · Randy Dunlap <hidden> · 2021-07-18

From: Christoph Hellwig <hch@infradead.org>
Date: 2021-07-16 09:14:06
Also in: linux-mm, mm-commits

On Fri, Jul 16, 2021 at 10:57:51AM +0200, Vlastimil Babka wrote:

On 7/16/21 9:39 AM, Christoph Hellwig wrote:

quoted

This somewhat unexpectedly causes a crash when running the xfs/433 test
in xfstests for me.  Reverting the commit fixes the problem:

That's weird, the backtrace doesn't even include SLUB/stackdepot code.
Is that kernel actually booted with slub_debug option/built with
CONFIG_SLUB_DEBUG_ON or some cache created with SLAB_STORE_USER ?

CONFIG_SLUB_DEBUG_ON is enabled, yes.  Full .config attached.

Attachments

config.gz [application/gzip] 35959 bytes

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help