On 8/6/24 04:02, Vlastimil Babka wrote:
On 8/6/24 04:40, Linus Torvalds wrote:
[ Let's drop random people and bring in Vlastimil ]
tglx was reproducing it so I add him back
Vlastimil,
it turns out that the "this patch" is entirely a red herring, and the
problem comes and goes randomly with just some code layout issues. See
http://server.roeck-us.net/qemu/parisc64-6.10.3/
for more detail, particularly you'll see the "log.bad.gz" with the full log.
[ 0.000000] BUG kmem_cache_node (Not tainted): objects 21 > max 16
[ 0.000000] Slab 0x0000000041ed0000 objects=21 used=5 fp=0x00000000434003d0 flags=0x200(workingset|section=0|zone=0)
flags tell us this came from the partial list (workingset), there's no head flag so order-0
since the error was detected it basically throws the slab page away and tries another one
[ 0.000000] BUG kmem_cache (Tainted: G B ): objects 25 > max 16
[ 0.000000] Slab 0x0000000041ed0080 objects=25 used=6 fp=0x0000000043402790 flags=0x240(workingset|head|section=0|zone=0)
this was also from the partial list but head flag so at least order-1, two things are weird:
- max=16 is same as above even though it should be at least double as
slab page's order is larger
- objects=25 also isn't at least twice than objects=21
All the following are:
[ 0.000000] BUG kmem_cache (Tainted: G B ): objects 25 > max 16
[ 0.000000] Slab 0x0000000041ed0300 objects=25 used=1 fp=0x000000004340c150 flags=0x40(head|section=0|zone=0)
we depleted the partial list so it's allocating new slab pages, that are
also at least order-1
It looks like maxobj calculation is bogus, would be useful to see what values it
calculates from. I'm attaching a diff, but maybe it will also hide the issue...
If I am really careful I can catch the problem. Adding a parameter to slab_err()
makes it disappear. Calling slab_order() multiple times makes it disappear. But I can
assign the result of slab_order() to a variable and go from there, by changing the
parameters to slab_err() one at a time. Here is what I get by combining multiple
test runs.
objects 21 max 16 order 0 size 192
with:
Slab 0x0000000041ed0000 objects=21 used=5 fp=0x00000000434003d0 flags=0x200(workingset|section=0|zone=0)
objects 25 max 16 order 1 size 320 (many times)
with:
Slab 0x0000000041ed0080 objects=25 used=6 fp=0x0000000043402790 flags=0x240(workingset|head|section=0|zone=0)
Slab 0x0000000041ed0300 objects=25 used=1 fp=0x000000004340c150 flags=0x40(head|section=0|zone=0)
Slab 0x0000000041ed0380 objects=25 used=1 fp=0x000000004340e150 flags=0x40(head|section=0|zone=0)
and so on
If I add a log message into check_slab() and display every check I get:
objects 21 max 21 (order 0 size 192)
objects 25 max 25 (order 1 size 320)
objects 25 max 25 (order 1 size 320)
objects 25 max 25 (order 1 size 320)
objects 21 max 21 (order 0 size 192)
and so on. I guess that confirms that the maxobj calculation is wrong in the failure case.
That seems weird, though, given that order_objects() should return a constant based on
order and size. PAGE_SIZE is 4096, meaning order_objects() should return 21 and 25, never
16. That does make me really wonder if there is an emulation problem, though I don't
really understand why that would not be persistent.
Any idea what else I could test ?
Thanks,
Guenter
