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. ... "