[0/1] Fix slub_debug on 5.9-rc

Message

Eric Farman Sept. 30, 2020, 11:26 a.m. UTC

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(-)