Re: [PATCH 6.10 000/809] 6.10.3-rc3 review

[Thomas Gleixner <tglx@linutronix.de>]

On Tue, Aug 06 2024 at 13:02, Vlastimil Babka wrote:
> On 8/6/24 04:40, Linus Torvalds wrote:
> 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...

It does hide it :(

> If someone has a /proc/slabinfo from a working boot with otherwise same config
> it might be also enough to guess what values should be expected there,
> at least the s-size.
>
> objects=21 vs 25 also seem odd though
>
> used=5 with used=6 in the first two also suggests we already passed this code
> successfully for creating a number of kmalloc caches and only then it started
> failing, that's also weird.

I added a printk() to check_slab() and on the non-failing boot this
looks like:

[    0.000000] c 000000004017b0f8 c 0000000041ed0000 objects 21 max 21 order 0 size 192, inuse 2
[    0.000000] c 000000004017b1c8 c 0000000041ed0080 objects 25 max 25 order 1 size 320, inuse 1
[    0.000000] c 0000000043402010 c 0000000041ed0080 objects 25 max 25 order 1 size 320, inuse 2
[    0.000000] c 0000000043402010 c 0000000041ed0080 objects 25 max 25 order 1 size 320, inuse 3
[    0.000000] c 0000000043402150 c 0000000041ed0000 objects 21 max 21 order 0 size 192, inuse 3
[    0.000000] c 0000000043402010 c 0000000041ed0080 objects 25 max 25 order 1 size 320, inuse 4
[    0.000000] c 0000000043402150 c 0000000041ed0000 objects 21 max 21 order 0 size 192, inuse 4
[    0.000000] c 0000000043402010 c 0000000041ed0080 objects 25 max 25 order 1 size 320, inuse 5
[    0.000000] c 0000000043402150 c 0000000041ed0000 objects 21 max 21 order 0 size 192, inuse 5
[    0.000000] c 0000000043402010 c 0000000041ed0080 objects 25 max 25 order 1 size 320, inuse 6
[    0.000000] c 0000000043402150 c 0000000041ed0000 objects 21 max 21 order 0 size 192, inuse 6

I did some more experiments to figure out why adding or removing text
cures it. The minimal change which makes it boot again is:

 asmlinkage __visible void __softirq_entry __do_softirq(void)
 {
+	current->flags &= ~PF_MEMALLOC;
 	handle_softirqs(false);
 }

That results in the following System.map delta:

--- ../upstream.txt	2024-08-06 16:52:49.746528992 +0200
+++ ../build-misc/System.map	2024-08-06 19:02:32.652201977 +0200
@@ -47600,15 +47600,15 @@
 0000000041218c30 T __do_softirq
 0000000041218c30 T __irqentry_text_end
 0000000041218c30 T __softirqentry_text_start
-0000000041218c70 T $$divoI
-0000000041218c70 T __softirqentry_text_end
-00000000412190d0 T $$divI_2
-00000000412190d0 T $$divide_by_constant
-00000000412190e0 T $$divI_4
-00000000412190f0 T $$divI_8
-0000000041219100 T $$divI_16
-00000000412192d8 T $$divI_17
-000000004121930c T $$divU_17
+0000000041218c80 T $$divoI
+0000000041218c80 T __softirqentry_text_end
+00000000412190e0 T $$divI_2
+00000000412190e0 T $$divide_by_constant
+00000000412190f0 T $$divI_4
+0000000041219100 T $$divI_8
+0000000041219110 T $$divI_16
+00000000412192e8 T $$divI_17
+000000004121931c T $$divU_17
 000000004121a000 D __start_opd
 000000004121a000 D _etext
 000000004121a000 D _sdata

So this change adds 16 bytes to __softirq() which moves the division
functions up by 16 bytes. That's all it takes to make the stupid go
away....

I wonder whether this is some qemu stupid.

Thanks,

        tglx