On 8/8/24 02:57, Thomas Gleixner wrote:
On Wed, Aug 07 2024 at 18:07, Guenter Roeck wrote:On 8/6/24 16:24, Thomas Gleixner wrote: diff --git a/mm/slub.c b/mm/slub.c index 4927edec6a8c..b8a33966d858 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1385,6 +1385,9 @@ static int check_slab(struct kmem_cache *s, struct slab *slab) } maxobj = order_objects(slab_order(slab), s->size); + + pr_info_once("##### slab->objects=%u maxobj=%u\n", slab->objects, maxobj); + if (slab->objects > maxobj) { slab_err(s, slab, "objects %u > max %u", slab->objects, maxobj); results in: ##### slab->objects=21 maxobj=21 ============================================================================= BUG kmem_cache_node (Not tainted): objects 21 > max 16Careful vs. the pr_once(). It's not necessarily the first allocation
Yes. Thanks for pointing that out. Rookie mistake :-(.
which trips up. I removed slab_err() in that condition and just printed the data: [ 0.000000] Order: 1 Size: 384 Nobj: 21 Maxobj: 16 21 Inuse: 14 [ 0.000000] Order: 0 Size: 168 Nobj: 24 Maxobj: 16 24 Inuse: 1 [ 0.000000] Order: 1 Size: 320 Nobj: 25 Maxobj: 16 25 Inuse: 18 [ 0.000000] Order: 1 Size: 320 Nobj: 25 Maxobj: 16 25 Inuse: 19 [ 0.000000] Order: 1 Size: 320 Nobj: 25 Maxobj: 16 25 Inuse: 20 [ 0.000000] Order: 0 Size: 160 Nobj: 25 Maxobj: 16 25 Inuse: 5 [ 0.000000] Order: 2 Size: 672 Nobj: 24 Maxobj: 16 24 Inuse: 1 [ 0.000000] Order: 3 Size: 1536 Nobj: 21 Maxobj: 16 21 Inuse: 1 [ 0.000000] Order: 3 Size: 1536 Nobj: 21 Maxobj: 16 21 Inuse: 2 [ 0.000000] Order: 3 Size: 1536 Nobj: 21 Maxobj: 16 21 Inuse: 10 The maxobj column shows the failed result and the result from the second invocation inside of the printk(). Let's wait for PARISC people to run it on actual hardware.
Agreed. I suspect that there is a carry or upper 32 bit of a register not handled properly, but I have no idea where that might be or why that would only be seen if the div functions are located in a certain address range. Thanks, Guenter
