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
