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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <90e02d99-37a2-437e-ad42-44b80c4e94f6@suse.cz>
Date: Tue, 6 Aug 2024 21:25:18 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Thomas Gleixner <tglx@...utronix.de>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 Guenter Roeck <linux@...ck-us.net>
Cc: linux-kernel@...r.kernel.org, Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH 6.10 000/809] 6.10.3-rc3 review

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