[PATCH 1/1] mm/mm_init: compute hash mask with unsigned arithmetic

[PATCH 1/1] mm/mm_init: compute hash mask with unsigned arithmetic

[Longlong Xia]

From: Longlong Xia <xialonglong@kylinos.cn>

alloc_large_system_hash() allows up to 2^31 buckets, so log2qty can
reach 31. At that limit, the current expression relies on signed
integer wrapping to produce the unsigned hash mask.

Use an unsigned literal so the mask is computed with unsigned
arithmetic. Supported compiler settings already produce the same
result, so this is a source-level cleanup with no functional change.

Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Longlong Xia <xialonglong@kylinos.cn>
---
 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 498d62c4ece3..1883fe923ffb 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -2469,7 +2469,7 @@ void *__init alloc_large_system_hash(const char *tablename,
 	if (_hash_shift)
 		*_hash_shift = log2qty;
 	if (_hash_mask)
-		*_hash_mask = (1 << log2qty) - 1;
+		*_hash_mask = (1U << log2qty) - 1;
 
 	return table;
 }
-- 
2.43.0

Re: [PATCH 1/1] mm/mm_init: compute hash mask with unsigned arithmetic

[Mike Rapoport]

Hi,

On Sun, Aug 09, 2026 at 08:31:19PM +0800, Longlong Xia wrote:
> From: Longlong Xia <xialonglong@kylinos.cn>
> 
> alloc_large_system_hash() allows up to 2^31 buckets, so log2qty can
> reach 31. At that limit, the current expression relies on signed
> integer wrapping to produce the unsigned hash mask.
> 
> Use an unsigned literal so the mask is computed with unsigned
> arithmetic. Supported compiler settings already produce the same
> result, so this is a source-level cleanup with no functional change.

If complier already takes care of this then why do we want this patch?
 
> Assisted-by: Codex:gpt-5.6-sol
> Signed-off-by: Longlong Xia <xialonglong@kylinos.cn>
> ---
>  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 498d62c4ece3..1883fe923ffb 100644
> --- a/mm/mm_init.c
> +++ b/mm/mm_init.c
> @@ -2469,7 +2469,7 @@ void *__init alloc_large_system_hash(const char *tablename,
>  	if (_hash_shift)
>  		*_hash_shift = log2qty;
>  	if (_hash_mask)
> -		*_hash_mask = (1 << log2qty) - 1;
> +		*_hash_mask = (1U << log2qty) - 1;
>  
>  	return table;
>  }
> -- 
> 2.43.0
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 1/1] mm/mm_init: compute hash mask with unsigned arithmetic

[Longlong Xia]

在 2026/8/9 22:03, Mike Rapoport 写道:
> Hi,
>
> On Sun, Aug 09, 2026 at 08:31:19PM +0800, Longlong Xia wrote:
>> From: Longlong Xia <xialonglong@kylinos.cn>
>>
>> alloc_large_system_hash() allows up to 2^31 buckets, so log2qty can
>> reach 31. At that limit, the current expression relies on signed
>> integer wrapping to produce the unsigned hash mask.
>>
>> Use an unsigned literal so the mask is computed with unsigned
>> arithmetic. Supported compiler settings already produce the same
>> result, so this is a source-level cleanup with no functional change.
> If complier already takes care of this then why do we want this patch?
>   
Fair point. Since supported compilers already produce the intended 
result and this patch has no functional impact, the benefit is only 
making the unsigned arithmetic explicit. So please disregard this patch.

Thanks for the review.

Best regards,
Longlong

>> Assisted-by: Codex:gpt-5.6-sol
>> Signed-off-by: Longlong Xia <xialonglong@kylinos.cn>
>> ---
>>   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 498d62c4ece3..1883fe923ffb 100644
>> --- a/mm/mm_init.c
>> +++ b/mm/mm_init.c
>> @@ -2469,7 +2469,7 @@ void *__init alloc_large_system_hash(const char *tablename,
>>   	if (_hash_shift)
>>   		*_hash_shift = log2qty;
>>   	if (_hash_mask)
>> -		*_hash_mask = (1 << log2qty) - 1;
>> +		*_hash_mask = (1U << log2qty) - 1;
>>   
>>   	return table;
>>   }
>> -- 
>> 2.43.0
>>

Re: [PATCH 1/1] mm/mm_init: compute hash mask with unsigned arithmetic

[Andrew Morton]

On Sun, 9 Aug 2026 22:25:35 +0800 Longlong Xia <xialonglong2025@163.com> wrote:

> 在 2026/8/9 22:03, Mike Rapoport 写道:
> > Hi,
> >
> > On Sun, Aug 09, 2026 at 08:31:19PM +0800, Longlong Xia wrote:
> >> From: Longlong Xia <xialonglong@kylinos.cn>
> >>
> >> alloc_large_system_hash() allows up to 2^31 buckets, so log2qty can
> >> reach 31. At that limit, the current expression relies on signed
> >> integer wrapping to produce the unsigned hash mask.
> >>
> >> Use an unsigned literal so the mask is computed with unsigned
> >> arithmetic. Supported compiler settings already produce the same
> >> result, so this is a source-level cleanup with no functional change.
> > If complier already takes care of this then why do we want this patch?
> >   
> Fair point. Since supported compilers already produce the intended 
> result and this patch has no functional impact, the benefit is only 
> making the unsigned arithmetic explicit. So please disregard this patch.

It's a very small thing, but I believe the patch improves the code.

I mean, we erroneously compute a large negative number then subtract 1
from it then copy that larger negative number into a signed scalar.

The copied bit pattern happens to be what we'd have got if the code had
been correct, but the code isn't correct!

Re: [PATCH 1/1] mm/mm_init: compute hash mask with unsigned arithmetic

[Matthew Wilcox]

On Sun, Aug 09, 2026 at 06:14:00PM -0700, Andrew Morton wrote:
> > >> Use an unsigned literal so the mask is computed with unsigned
> > >> arithmetic. Supported compiler settings already produce the same
> > >> result, so this is a source-level cleanup with no functional change.
> > > If complier already takes care of this then why do we want this patch?
> >   
> > Fair point. Since supported compilers already produce the intended 
> > result and this patch has no functional impact, the benefit is only 
> > making the unsigned arithmetic explicit. So please disregard this patch.
> 
> It's a very small thing, but I believe the patch improves the code.
> 
> I mean, we erroneously compute a large negative number then subtract 1
> from it then copy that larger negative number into a signed scalar.

That is an erroneous description of this code.

1 << 31 is the largest-magnitude negative number, ie it's INT_MIN.
We then subtract one from it, so it wraps back around to INT_MAX.
So the number assigned to *_hash_mask is always positive.

> The copied bit pattern happens to be what we'd have got if the code had
> been correct, but the code isn't correct!

The code is correct as long as we compile with -fwrapv or whatever that
got renamed to.  And I don't see that changing.