On Wed, Jul 08, 2026 at 01:25:01AM +0200, Erhard Furtner wrote: ...
> > 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 <[email protected]> > 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 <[email protected]> > Signed-off-by: Yury Norov <[email protected]> > > 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
