diff mbox series

[v2] maple_tree: Use correct variable type in sizeof

Message ID 20230411023513.15227-1-zhangpeng.00@bytedance.com
State New
Headers
Series [v2] maple_tree: Use correct variable type in sizeof |

Commit Message

Peng Zhang April 11, 2023, 2:35 a.m. UTC 
  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(-)

Comments

Andrew Morton April 11, 2023, 3:29 a.m. UTC | #1 
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)?
Matthew Wilcox April 11, 2023, 3:42 a.m. UTC | #2 
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.
Peng Zhang April 11, 2023, 3:49 a.m. UTC | #3 
在 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.
>
Andrew Morton April 11, 2023, 3:58 a.m. UTC | #4 
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.
diff mbox series

Patch

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));