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
