linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/1] Fix slub_debug on 5.9-rc
@ 2020-09-30 11:26 Eric Farman
  2020-09-30 11:26 ` [PATCH 1/1] mm, slub: Restore initial kmem_cache flags Eric Farman
  0 siblings, 1 reply; 6+ messages in thread
From: Eric Farman @ 2020-09-30 11:26 UTC (permalink / raw)
  To: Vlastimil Babka
  Cc: Christoph Lameter, Pekka Enberg, David Rientjes, Joonsoo Kim,
	Andrew Morton, Kees Cook, linux-mm, Eric Farman

Hi Vlastimil, et al,

Apologies in advance, for I am way out of my element at the moment.

I wanted to use slub_debug for a problem I'm looking at, and since
the slab in question is always the same I added this:

  slub_debug=FZ,dma-kmalloc-8

But then my system just crashes on bringup (using the 5.9 RCs):

[    6.712339] Unable to handle kernel pointer dereference in virtual kernel address space
[    6.712344] Failing address: 0000004400000000 TEID: 0000004400000803
[    6.712346] Fault in home space mode while using kernel ASCE.
[    6.712351] AS:00000000221ec007 R3:0000000000000024
[    6.712406] Oops: 003b ilc:3 [#1] SMP
[    6.712410] Modules linked in: pkey zcrypt rng_core
[    6.712415] CPU: 6 PID: 8 Comm: kworker/u564:0 Not tainted 5.9.0-rc7 #4
[    6.712418] Hardware name: IBM 2964 NE1 749 (LPAR)

The same option works fine on 5.8, so I bisected mm/ and ended up
blaming commit e17f1dfba37b ("mm, slub: extend slub_debug syntax for 
multiple blocks"). I didn't bother reverting this from 5.9, because
of the neighboring rework that this was a part of, but I did apply
it to 5.8, and recreated the problem there.

Looking at the above commit, I note that kmem_cache_flags() now
returns slub_debug instead of flags, which leads every kmem_cache
(other than one I'm trying to debug) getting its flags set to zero.
That wasn't the case previously, and seems quite suspect:

[    0.709206] s->name=dma-kmalloc-96 flags=4000 s->flags=0
[    0.709227] s->name=dma-kmalloc-192 flags=4000 s->flags=0
[    0.709248] s->name=dma-kmalloc-8 flags=4000 s->flags=4500
[    0.709269] s->name=dma-kmalloc-16 flags=4000 s->flags=0
[    0.709290] s->name=dma-kmalloc-32 flags=4000 s->flags=0

If I change my slab_list to "dma-kmalloc-*", and all dma slabs get
assigned the debug flags in addition to DMA, the panic seen on boot
disappears and my system comes up. I didn't leave my system up long
enoughu to see if weirdness on the other slabs occurred, but I
suspect it would.

I am running on s390, with defconfig, but I don't think that matters
here. Either way, the attached patch restores the variable that this
routine returns for slabs not affected by slub_debug, and lets my
system boot with various combinations of slub_debug parameters that
I've tried. Hopefully it's close to what is needed here.

I look forward to hearing your thoughts on this, and am happy to try
other things if I'm too far into the weeds. Thanks!

Eric Farman (1):
  mm, slub: Restore initial kmem_cache flags

 mm/slub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.17.1



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-09-30 16:19 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-30 11:26 [PATCH 0/1] Fix slub_debug on 5.9-rc Eric Farman
2020-09-30 11:26 ` [PATCH 1/1] mm, slub: Restore initial kmem_cache flags Eric Farman
2020-09-30 11:37   ` Vlastimil Babka
2020-09-30 13:06     ` Eric Farman
2020-09-30 13:54       ` Vlastimil Babka
2020-09-30 16:19         ` [PATCH v2] " Eric Farman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).