Re: [PATCH] mm: drop stale MAX_ORDER references

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Blind text replacement in a comment causes the documented mathematical formula for maximum page allocation size to be halved.
--

--- Patch [1]: [PATCH] mm: drop stale MAX_ORDER references ---
commit dbb29499acbd8adcdd7b1a04573e7581c99841f4
Author: Qi Xi <xiqi2@huawei.com>

mm: drop stale MAX_ORDER references

This commit renames leftover instances of MAX_ORDER to MAX_PAGE_ORDER across
the tree, including comments and gdb helper scripts, to maintain consistency
after the treewide rename.

> diff --git a/include/net/mana/mana.h b/include/net/mana/mana.h
> index 04acb6791dbd9..1d5bed71d6a7e 100644
> --- a/include/net/mana/mana.h
> +++ b/include/net/mana/mana.h
> @@ -40,8 +40,8 @@ enum TRI_STATE {
>  #define COMP_ENTRY_SIZE 64
>  
>  /* This Max value for RX buffers is derived from __alloc_page()'s max page
> - * allocation calculation. It allows maximum 2^(MAX_ORDER -1) pages. RX buffer
> - * size beyond this value gets rejected by __alloc_page() call.
> + * allocation calculation. It allows maximum 2^(MAX_PAGE_ORDER -1) pages. RX
> + * buffer size beyond this value gets rejected by __alloc_page() call.

[Severity: Low]
Does this direct text replacement inadvertently halve the documented
maximum page allocation size?

The old formula used 2^(MAX_ORDER - 1). Because MAX_PAGE_ORDER is an
inclusive limit that is one less than the old exclusive MAX_ORDER, evaluating
2^(MAX_PAGE_ORDER - 1) results in half the actual maximum pages.

Should this formula be updated to just 2^MAX_PAGE_ORDER instead?

>   */
>  #define MAX_RX_BUFFERS_PER_QUEUE 8192
>  #define DEF_RX_BUFFERS_PER_QUEUE 1024

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818122408.4182417-1-xiqi2@huawei.com?part=1