Re: [PATCH v1] mm/mm_init: Fix hash table order logging in alloc_large_system_hash()

[David Hildenbrand]

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@xxxxxxxxxxxxxxx # 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