On 8/6/24 19:33, Thomas Gleixner wrote:
> 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....
Heh I was actually wondering if the division is somhow messed up because
maxobj = order_objects() and order_objects() does a division. Now I suspect
it even more.
> I wonder whether this is some qemu stupid.
>
> Thanks,
>
> tglx
