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.
Signed-off-by: Isaac J. Manjarres isaacmanjarres@google.com
mm/mm_init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/mm_init.c b/mm/mm_init.c index 3db2dea7db4c..7712d887b696 100644 --- a/mm/mm_init.c +++ b/mm/mm_init.c @@ -2469,7 +2469,7 @@ void *__init alloc_large_system_hash(const char *tablename, panic("Failed to allocate %s hash table\n", tablename); pr_info("%s hash table entries: %ld (order: %d, %lu bytes, %s)\n",
tablename, 1UL << log2qty, ilog2(size) - PAGE_SHIFT, size,
tablename, 1UL << log2qty, get_order(size), size,So in case it's smaller than a page we now correctly return "0".
Correct.
Reviewed-by: David Hildenbrand david@redhat.com
-- Cheers
David / dhildenb
Thanks! Isaac