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: <CAHk-=wjmumbT73xLkSAnnxDwaFE__Ny=QCp6B_LE2aG1SUqiTg@mail.gmail.com>
Date: Tue, 6 Aug 2024 10:34:57 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: Vlastimil Babka <vbabka@...e.cz>, linux-kernel@...r.kernel.org, 
	Linux-MM <linux-mm@...ck.org>, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 6.10 000/809] 6.10.3-rc3 review

On Tue, 6 Aug 2024 at 10:20, Guenter Roeck <linux@...ck-us.net> wrote:
>
> kmem_cache_node      197    210    192   21    1 : tunables    0    0    0 : slabdata     10     10      0
> kmem_cache           197    200    320   25    2 : tunables    0    0    0 : slabdata      8      8      0

Hmm. Do we have some alignment confusion?

The alignment rules for 192 are to align it to 64-byte boundaries
(because that's the largest power of two that divides it), and that
means it stays at 192, and that would give 21 objects per 4kB page.

But if we use the "align up to next power of two", you get 256 bytes,
and 16 objects per page.

And that 21-vs-16 confusion would seem to match this pretty well:

  [    0.000000] BUG kmem_cache_node (Not tainted): objects 21 > max 16

which makes me wonder...

            Linus