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

[David Hildenbrand <david@redhat.com>]

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@vger.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