linux-kernel - Re: [PATCH v1] mm/mm_init: Fix hash table order logging in alloc_large_system

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] [day] [month] [year] [list]

Message-ID: <aQI7PvFcpxFd_IHv@google.com>
Date: Wed, 29 Oct 2025 09:05:18 -0700
From: Isaac Manjarres <isaacmanjarres@...gle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Mike Rapoport <rppt@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>, stable@...r.kernel.org,
	kernel-team@...roid.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] mm/mm_init: Fix hash table order logging in
 alloc_large_system_hash()

On Wed, Oct 29, 2025 at 04:58:37PM +0100, David Hildenbrand wrote:
> On 29.10.25 16:50, Isaac Manjarres wrote:
> > On Wed, Oct 29, 2025 at 11:03:18AM +0100, David Hildenbrand wrote:
> > > On 28.10.25 20:10, Isaac J. Manjarres wrote:
> > > > When emitting the order of the allocation for a hash table,
> > > > alloc_large_system_hash() unconditionally subtracts PAGE_SHIFT from
> > > > log base 2 of the allocation size. This is not correct if the
> > > > allocation size is smaller than a page, and yields a negative value
> > > > for the order as seen below:
> > > > 
> > > > TCP established hash table entries: 32 (order: -4, 256 bytes, linear)
> > > > TCP bind hash table entries: 32 (order: -2, 1024 bytes, linear)
> > > > 
> > > > Use get_order() to compute the order when emitting the hash table
> > > > information to correctly handle cases where the allocation size is
> > > > smaller than a page:
> > > > 
> > > > TCP established hash table entries: 32 (order: 0, 256 bytes, linear)
> > > > TCP bind hash table entries: 32 (order: 0, 1024 bytes, linear)
> > > > 
> > > > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > > > Cc: stable@...r.kernel.org # v5.4+
> > > 
> > > This is a pr_info(), why do you think this is stable material? Just curious,
> > > intuitively I'd have said that it's not that critical.
> > > 
> > 
> > Hi David,
> > 
> > Thank you for taking the time to review this patch! I was just under the
> > impression that any bug--even those for informational logging--should be
> > sent to stable as well.
> 
> See https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> 
> In particular:
> 
> "
> It fixes a problem like an oops, a hang, data corruption, a real security
> issue, a hardware quirk, a build error (but not for things marked
> CONFIG_BROKEN), or some “oh, that’s not good” issue.
> 
> Serious issues as reported by a user of a distribution kernel may also be
> considered if they fix a notable performance or interactivity issue. ...
> "
> 
> -- 
> Cheers
> 
> David / dhildenb
> 

Thank you for pointing that out, sorry about that. I'll keep that in
mind moving forward.

Thanks,
Isaac