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 <[email protected]>
Signed-off-by: Peng Zhang <[email protected]>
Reviewed-by: Liam R. Howlett <[email protected]>
Cc: <[email protected]>
---
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
On Tue, 11 Apr 2023 10:35:13 +0800 Peng Zhang <[email protected]> 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)?
On Mon, Apr 10, 2023 at 08:29:35PM -0700, Andrew Morton wrote:
> On Tue, 11 Apr 2023 10:35:13 +0800 Peng Zhang <[email protected]> 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.
在 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 <[email protected]> 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.
>
On Tue, 11 Apr 2023 11:49:56 +0800 Peng Zhang <[email protected]> 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 <[email protected]> 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.