Greetings!
I don't get this on my x86_64 machines, but on ppc32 (PowerMac G4 DP)
and on ppc64 (Talos II, POWER9) running Gentoo Linux. This dmesg snippet
is from the G4:
Total memory = 2048MB; using 4096kB for hash table
Activating Kernel Userspace Access Protection
Activating Kernel Userspace Execution Prevention
Linux version 7.2.0-rc2-PMacG4 (root@T1000) (gcc (Gentoo 15.3.0 p8)
15.3.0, GNU ld (Gentoo 2.46.0 p1) 2.46.0) #1 SMP PREEMPT Mon Jul 6
20:22:47 CEST 2026
[...]
test_bitmap: loaded.
test_bitmap: [lib/test_bitmap.c:397] bitmaps contents differ: expected
"1,3-4,9", got "1,3-4,9,65-71,73-79,81-87,89-95,97-99"
test_bitmap: parselist('0-2047:128/256'): 912
test_bitmap: scnprintf("%*pbl", '0-32767'): 5977
test_bitmap: test_bitmap_read_perf: 1191082
test_bitmap: test_bitmap_write_perf: 1270153
test_bitmap: failed 1 out of 208655 tests
Full dmesg available at request. Kernel .config attached.
Regards,
Erhard
Hi,
Le 06/07/2026 à 21:27, Erhard Furtner a écrit :
Greetings!
I don't get this on my x86_64 machines, but on ppc32 (PowerMac G4 DP)
and on ppc64 (Talos II, POWER9) running Gentoo Linux. This dmesg snippet
is from the G4:
Total memory = 2048MB; using 4096kB for hash table
Activating Kernel Userspace Access Protection
Activating Kernel Userspace Execution Prevention
Linux version 7.2.0-rc2-PMacG4 (root@T1000) (gcc (Gentoo 15.3.0 p8)
15.3.0, GNU ld (Gentoo 2.46.0 p1) 2.46.0) #1 SMP PREEMPT Mon Jul 6
20:22:47 CEST 2026
[...]
test_bitmap: loaded.
test_bitmap: [lib/test_bitmap.c:397] bitmaps contents differ: expected
"1,3-4,9", got "1,3-4,9,65-71,73-79,81-87,89-95,97-99"
test_bitmap: parselist('0-2047:128/256'): 912
test_bitmap: scnprintf("%*pbl", '0-32767'): 5977
test_bitmap: test_bitmap_read_perf: 1191082
test_bitmap: test_bitmap_write_perf: 1270153
test_bitmap: failed 1 out of 208655 tests
On QEMU (pmac32_defconfig) I get:
test_bitmap: loaded.
test_bitmap: parselist('0-2047:128/256'): 2200
test_bitmap: scnprintf("%*pbl", '0-32767'): 26440
test_bitmap: test_bitmap_read_perf: 1819760
test_bitmap: test_bitmap_write_perf: 18189840
test_bitmap: all 208655 tests passed
On QEMU with your confirm I get:
[ 1.162486] test_bitmap: loaded.
[ 1.177069] test_bitmap: [lib/test_bitmap.c:397] bitmaps contents
differ: expected "1,3-4,9", got "1,3-4,9,65-71,73-79,81-87,89-95,97-99"
[ 1.180599] test_bitmap: parselist('0-2047:128/256'): 2920
[ 1.190105] test_bitmap: scnprintf("%*pbl", '0-32767'): 65560
[ 1.427378] test_bitmap: test_bitmap_read_perf: 9546321
[ 1.438769] test_bitmap: test_bitmap_write_perf: 9344481
[ 1.457679] test_bitmap: failed 1 out of 208655 tests
So there is something with your config
Full dmesg available at request. Kernel .config attached.
Regards,
Erhard
On QEMU (pmac32_defconfig) I get:
test_bitmap: loaded.
test_bitmap: parselist('0-2047:128/256'): 2200
test_bitmap: scnprintf("%*pbl", '0-32767'): 26440
test_bitmap: test_bitmap_read_perf: 1819760
test_bitmap: test_bitmap_write_perf: 18189840
test_bitmap: all 208655 tests passed
On QEMU with your confirm I get:
[ 1.162486] test_bitmap: loaded.
[ 1.177069] test_bitmap: [lib/test_bitmap.c:397] bitmaps contents
differ: expected "1,3-4,9", got "1,3-4,9,65-71,73-79,81-87,89-95,97-99"
[ 1.180599] test_bitmap: parselist('0-2047:128/256'): 2920
[ 1.190105] test_bitmap: scnprintf("%*pbl", '0-32767'): 65560
[ 1.427378] test_bitmap: test_bitmap_read_perf: 9546321
[ 1.438769] test_bitmap: test_bitmap_write_perf: 9344481
[ 1.457679] test_bitmap: failed 1 out of 208655 tests
So there is something with your config
Interesting! As I get the same test failure on my Talos II too.
Anyhow, I was able to bisect the issue. Offending commit is:
# git bisect bad
6b5a4b68736798df1031404a2fad06d031253ef7 is the first bad commit
commit 6b5a4b68736798df1031404a2fad06d031253ef7 (HEAD)
Author: Andy Shevchenko [off-list ref]
Date: Thu Feb 26 12:16:44 2026 +0100
bitmap: Add test for out-of-boundary modifications for scatter & gather
Make sure that bitmap_scatter() and bitmap_gather() do not modify
the bits outside of the given nbits span.
Signed-off-by: Andy Shevchenko [off-list ref]
Signed-off-by: Yury Norov [off-list ref]
lib/test_bitmap.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
Reverting this commit on top of v7.2-rc2 lets the test pass:
test_bitmap: loaded.
test_bitmap: parselist('0-2047:128/256'): 888
test_bitmap: scnprintf("%*pbl", '0-32767'): 6074
test_bitmap: test_bitmap_read_perf: 1190938
test_bitmap: test_bitmap_write_perf: 1259471
test_bitmap: all 208655 tests passed
Your hint about my config made me check a few options and I found the
offending one, which is INIT_STACK_ALL_PATTERN=y. On a kernel built with
INIT_STACK_ALL_ZERO=y the issue does not show up.
Regards,
Erhard
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2026-07-08 07:43:58
On Wed, Jul 08, 2026 at 01:25:01AM +0200, Erhard Furtner wrote:
...
quoted
So there is something with your config
Interesting! As I get the same test failure on my Talos II too.
Anyhow, I was able to bisect the issue. Offending commit is:
# git bisect bad
6b5a4b68736798df1031404a2fad06d031253ef7 is the first bad commit
commit 6b5a4b68736798df1031404a2fad06d031253ef7 (HEAD)
Author: Andy Shevchenko [off-list ref]
Date: Thu Feb 26 12:16:44 2026 +0100
bitmap: Add test for out-of-boundary modifications for scatter & gather
Make sure that bitmap_scatter() and bitmap_gather() do not modify
the bits outside of the given nbits span.
Signed-off-by: Andy Shevchenko [off-list ref]
Signed-off-by: Yury Norov [off-list ref]
lib/test_bitmap.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
Reverting this commit on top of v7.2-rc2 lets the test pass:
test_bitmap: loaded.
test_bitmap: parselist('0-2047:128/256'): 888
test_bitmap: scnprintf("%*pbl", '0-32767'): 6074
test_bitmap: test_bitmap_read_perf: 1190938
test_bitmap: test_bitmap_write_perf: 1259471
test_bitmap: all 208655 tests passed
Your hint about my config made me check a few options and I found the
offending one, which is INIT_STACK_ALL_PATTERN=y. On a kernel built with
INIT_STACK_ALL_ZERO=y the issue does not show up.
Oh, this is nice. So, there are two (more?) options I see to mitigate
the issue:
- carefully copy the garbage from the stack to the expected values
(effectively merge the whatever is on stack with the expected value)
- allocate buffers on heap
The latter seems the easiest and right thing to do (since we can't really
predict if the stack pattern is the same or bitmap APIs scatters the bits
just on top of the respective set or clear ones over that pattern).
I will send a patch, thanks for the report and analysis!
--
With Best Regards,
Andy Shevchenko
On Wed, Jul 08, 2026 at 01:25:01AM +0200, Erhard Furtner wrote:
...
quoted
quoted
So there is something with your config
Interesting! As I get the same test failure on my Talos II too.
Anyhow, I was able to bisect the issue. Offending commit is:
# git bisect bad
6b5a4b68736798df1031404a2fad06d031253ef7 is the first bad commit
commit 6b5a4b68736798df1031404a2fad06d031253ef7 (HEAD)
Author: Andy Shevchenko [off-list ref]
Date: Thu Feb 26 12:16:44 2026 +0100
bitmap: Add test for out-of-boundary modifications for scatter & gather
Make sure that bitmap_scatter() and bitmap_gather() do not modify
the bits outside of the given nbits span.
Signed-off-by: Andy Shevchenko [off-list ref]
Signed-off-by: Yury Norov [off-list ref]
lib/test_bitmap.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
Reverting this commit on top of v7.2-rc2 lets the test pass:
test_bitmap: loaded.
test_bitmap: parselist('0-2047:128/256'): 888
test_bitmap: scnprintf("%*pbl", '0-32767'): 6074
test_bitmap: test_bitmap_read_perf: 1190938
test_bitmap: test_bitmap_write_perf: 1259471
test_bitmap: all 208655 tests passed
Your hint about my config made me check a few options and I found the
offending one, which is INIT_STACK_ALL_PATTERN=y. On a kernel built with
INIT_STACK_ALL_ZERO=y the issue does not show up.
Oh, this is nice. So, there are two (more?) options I see to mitigate
the issue:
- carefully copy the garbage from the stack to the expected values
(effectively merge the whatever is on stack with the expected value)
- allocate buffers on heap
The latter seems the easiest and right thing to do (since we can't really
predict if the stack pattern is the same or bitmap APIs scatters the bits
just on top of the respective set or clear ones over that pattern).
I will send a patch, thanks for the report and analysis!
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Date: 2026-07-08 10:52:37
On Wed, Jul 08, 2026 at 09:51:34AM +0200, Christophe Leroy (CS GROUP) wrote:
Le 08/07/2026 à 09:43, Andy Shevchenko a écrit :
quoted
On Wed, Jul 08, 2026 at 01:25:01AM +0200, Erhard Furtner wrote:
...
quoted
Oh, this is nice. So, there are two (more?) options I see to mitigate
the issue:
- carefully copy the garbage from the stack to the expected values
(effectively merge the whatever is on stack with the expected value)
- allocate buffers on heap
The latter seems the easiest and right thing to do (since we can't really
predict if the stack pattern is the same or bitmap APIs scatters the bits
just on top of the respective set or clear ones over that pattern).
I will send a patch, thanks for the report and analysis!
The following change fixes the issue for me:
Indeed, I missed that and before seeing this message I also realised that this
is the probably best fix. Can you submit it as a formal patch, please?
Oh, this is nice. So, there are two (more?) options I see to mitigate
the issue:
- carefully copy the garbage from the stack to the expected values
(effectively merge the whatever is on stack with the expected value)
- allocate buffers on heap
The latter seems the easiest and right thing to do (since we can't really
predict if the stack pattern is the same or bitmap APIs scatters the bits
just on top of the respective set or clear ones over that pattern).
I will send a patch, thanks for the report and analysis!