linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2] maple_tree: Use correct variable type in sizeof
@ 2023-04-11  2:35 Peng Zhang
  2023-04-11  3:29 ` Andrew Morton
  0 siblings, 1 reply; 5+ messages in thread
From: Peng Zhang @ 2023-04-11  2:35 UTC (permalink / raw)
  To: Liam.Howlett
  Cc: akpm, linux-mm, linux-kernel, maple-tree, Peng Zhang,
	David Binderman, stable

The type of variable pointed to by pivs is unsigned long, but the type
used in sizeof is a pointer type. Change it to unsigned long.

Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Peng Zhang <zhangpeng.00@bytedance.com>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Cc: <stable@vger.kernel.org>
---
 lib/maple_tree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 88c44f6d6cee..b06fc5f19b31 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -3255,7 +3255,7 @@ static inline void mas_destroy_rebalance(struct ma_state *mas, unsigned char end
 
 		if (tmp < max_p)
 			memset(pivs + tmp, 0,
-			       sizeof(unsigned long *) * (max_p - tmp));
+			       sizeof(unsigned long) * (max_p - tmp));
 
 		if (tmp < mt_slots[mt])
 			memset(slots + tmp, 0, sizeof(void *) * (max_s - tmp));
-- 
2.20.1



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] maple_tree: Use correct variable type in sizeof
  2023-04-11  2:35 [PATCH v2] maple_tree: Use correct variable type in sizeof Peng Zhang
@ 2023-04-11  3:29 ` Andrew Morton
  2023-04-11  3:42   ` Matthew Wilcox
  0 siblings, 1 reply; 5+ messages in thread
From: Andrew Morton @ 2023-04-11  3:29 UTC (permalink / raw)
  To: Peng Zhang
  Cc: Liam.Howlett, linux-mm, linux-kernel, maple-tree,
	David Binderman, stable

On Tue, 11 Apr 2023 10:35:13 +0800 Peng Zhang <zhangpeng.00@bytedance.com> wrote:

> The type of variable pointed to by pivs is unsigned long, but the type
> used in sizeof is a pointer type. Change it to unsigned long.

Thanks, but there's nothing in this changelog which explains why a
-stable backport is being proposed.  When fixing a bug, please always
describe the user-visible effects of that bug.

> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -3255,7 +3255,7 @@ static inline void mas_destroy_rebalance(struct ma_state *mas, unsigned char end
>  
>  		if (tmp < max_p)
>  			memset(pivs + tmp, 0,
> -			       sizeof(unsigned long *) * (max_p - tmp));
> +			       sizeof(unsigned long) * (max_p - tmp));
>  
>  		if (tmp < mt_slots[mt])
>  			memset(slots + tmp, 0, sizeof(void *) * (max_s - tmp));

Is there any situation in which
sizeof(unsigned long *) != sizeof(unsigned long)?


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] maple_tree: Use correct variable type in sizeof
  2023-04-11  3:29 ` Andrew Morton
@ 2023-04-11  3:42   ` Matthew Wilcox
  2023-04-11  3:49     ` Peng Zhang
  0 siblings, 1 reply; 5+ messages in thread
From: Matthew Wilcox @ 2023-04-11  3:42 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Peng Zhang, Liam.Howlett, linux-mm, linux-kernel, maple-tree,
	David Binderman, stable

On Mon, Apr 10, 2023 at 08:29:35PM -0700, Andrew Morton wrote:
> On Tue, 11 Apr 2023 10:35:13 +0800 Peng Zhang <zhangpeng.00@bytedance.com> wrote:
> 
> > The type of variable pointed to by pivs is unsigned long, but the type
> > used in sizeof is a pointer type. Change it to unsigned long.
> 
> Thanks, but there's nothing in this changelog which explains why a
> -stable backport is being proposed.  When fixing a bug, please always
> describe the user-visible effects of that bug.

There is no user-visible effect of this bug as the assembly code
generated will be identical.

> > --- a/lib/maple_tree.c
> > +++ b/lib/maple_tree.c
> > @@ -3255,7 +3255,7 @@ static inline void mas_destroy_rebalance(struct ma_state *mas, unsigned char end
> >  
> >  		if (tmp < max_p)
> >  			memset(pivs + tmp, 0,
> > -			       sizeof(unsigned long *) * (max_p - tmp));
> > +			       sizeof(unsigned long) * (max_p - tmp));
> >  
> >  		if (tmp < mt_slots[mt])
> >  			memset(slots + tmp, 0, sizeof(void *) * (max_s - tmp));
> 
> Is there any situation in which
> sizeof(unsigned long *) != sizeof(unsigned long)?

Windows 64-bit (pointer 64-bit, unsigned long is 32 bit) is the only
one I know.  Linux is all ILP32 or LP64.  There may be some embedded
environments which are different, but I have no idea what they might be.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] maple_tree: Use correct variable type in sizeof
  2023-04-11  3:42   ` Matthew Wilcox
@ 2023-04-11  3:49     ` Peng Zhang
  2023-04-11  3:58       ` Andrew Morton
  0 siblings, 1 reply; 5+ messages in thread
From: Peng Zhang @ 2023-04-11  3:49 UTC (permalink / raw)
  To: Matthew Wilcox, Andrew Morton
  Cc: Peng Zhang, Liam.Howlett, linux-mm, linux-kernel, maple-tree,
	David Binderman, stable


在 2023/4/11 11:42, Matthew Wilcox 写道:
> On Mon, Apr 10, 2023 at 08:29:35PM -0700, Andrew Morton wrote:
>> On Tue, 11 Apr 2023 10:35:13 +0800 Peng Zhang <zhangpeng.00@bytedance.com> wrote:
>>
>>> The type of variable pointed to by pivs is unsigned long, but the type
>>> used in sizeof is a pointer type. Change it to unsigned long.
>> Thanks, but there's nothing in this changelog which explains why a
>> -stable backport is being proposed.  When fixing a bug, please always
>> describe the user-visible effects of that bug.
> There is no user-visible effect of this bug as the assembly code
> generated will be identical.

Therefore, if this has always been the case, cc stable
is also unnecessary.

>
>>> --- a/lib/maple_tree.c
>>> +++ b/lib/maple_tree.c
>>> @@ -3255,7 +3255,7 @@ static inline void mas_destroy_rebalance(struct ma_state *mas, unsigned char end
>>>   
>>>   		if (tmp < max_p)
>>>   			memset(pivs + tmp, 0,
>>> -			       sizeof(unsigned long *) * (max_p - tmp));
>>> +			       sizeof(unsigned long) * (max_p - tmp));
>>>   
>>>   		if (tmp < mt_slots[mt])
>>>   			memset(slots + tmp, 0, sizeof(void *) * (max_s - tmp));
>> Is there any situation in which
>> sizeof(unsigned long *) != sizeof(unsigned long)?
> Windows 64-bit (pointer 64-bit, unsigned long is 32 bit) is the only
> one I know.  Linux is all ILP32 or LP64.  There may be some embedded
> environments which are different, but I have no idea what they might be.
>


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH v2] maple_tree: Use correct variable type in sizeof
  2023-04-11  3:49     ` Peng Zhang
@ 2023-04-11  3:58       ` Andrew Morton
  0 siblings, 0 replies; 5+ messages in thread
From: Andrew Morton @ 2023-04-11  3:58 UTC (permalink / raw)
  To: Peng Zhang
  Cc: Matthew Wilcox, Liam.Howlett, linux-mm, linux-kernel, maple-tree,
	David Binderman, stable

On Tue, 11 Apr 2023 11:49:56 +0800 Peng Zhang <zhangpeng.00@bytedance.com> wrote:

> 在 2023/4/11 11:42, Matthew Wilcox 写道:
> > On Mon, Apr 10, 2023 at 08:29:35PM -0700, Andrew Morton wrote:
> >> On Tue, 11 Apr 2023 10:35:13 +0800 Peng Zhang <zhangpeng.00@bytedance.com> wrote:
> >>
> >>> The type of variable pointed to by pivs is unsigned long, but the type
> >>> used in sizeof is a pointer type. Change it to unsigned long.
> >> Thanks, but there's nothing in this changelog which explains why a
> >> -stable backport is being proposed.  When fixing a bug, please always
> >> describe the user-visible effects of that bug.
> > There is no user-visible effect of this bug as the assembly code
> > generated will be identical.
> 
> Therefore, if this has always been the case, cc stable
> is also unnecessary.

I removed the cc:stable, added

	This change has no runtime effect, as sizeof(ul) == sizeof(ul *).

and staged the patch for next merge window, thanks.


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-04-11  3:59 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-11  2:35 [PATCH v2] maple_tree: Use correct variable type in sizeof Peng Zhang
2023-04-11  3:29 ` Andrew Morton
2023-04-11  3:42   ` Matthew Wilcox
2023-04-11  3:49     ` Peng Zhang
2023-04-11  3:58       ` Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox