Re: [PATCH RESEND] sh: sq: Use the bitmap API when applicable
Christophe JAILLET <[email protected]>
| Newsgroups | gmane.linux.ports.sh.devel,gmane.linux.kernel,gmane.linux.kernel.janitors |
|---|---|
| Message-ID | <[email protected]> |
Le 18/04/2023 à 09:14, Geert Uytterhoeven a écrit :
>
> Nice catch!
>
> Looking more deeply at the code, the intention is to allocate a bitmap
> with nr_pages bits, so the code fater Christophe's patch is correct.
> However, the old code is indeed wrong:
>
> (nr_pages + (BITS_PER_LONG - 1)) / BITS_PER_LONG
>
> The aim is to calculate the size in bytes, rounded up to an integral
> number of longs, but it lacks a final multiplication by BITS_PER_BYTE,
> so it's off by a factor of 4.
>
> Fixes: d7c30c682a278abe ("sh: Store Queue API rework.")
>
> As we didn't have bitmap_zalloc() until commit c42b65e363ce97a8
> ("bitmap: Add bitmap_alloc(), bitmap_zalloc() and bitmap_free()")
> in v4.19, it would be good to fix the bug first in a separate patch,
> not using
>
> BTW, interesting how this got missed when fixing the other out-of-range
> bug in commit 9f650cf2b811cfb6 ("sh: Fix store queue bitmap end.",
> s/marc.theaimsgroup.com/marc.info/ when following the link).
So, this means that this got unnoticed for 16 years?
Waouh!
I would never have thought that a "trivial" clean-up that I took time to
repost could trigger such a thing!
Again.
Waouh!
Maybe, 0x04000000 is way to big?
Anyone knows where this value comes from?
Could there have been some memory corruption in real world application?
CJ
>
> Gr{oetje,eeting}s,
>
> Geert
>