From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 03BDD3F8231 for ; Wed, 8 Jul 2026 07:51:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783497106; cv=none; b=VV1rr49rQEnuCdU4WmHTvOZT90qCry+cKHHaHCcNTB6v7ayA16+0pjYhBH4teN87k5bWCClg7hQjf5lQsciI6eO6VRkmVbp8MXenuD0a0/1SQIHFg5B03qyxc5isF3MU6KY6hsMtdqnAS2N/Wifb0YB1XW+SaNFS5145d/Y1DNY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783497106; c=relaxed/simple; bh=qJmkR9T748zqRfNILGWuaq464qCPgiAWFwmyDvltons=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rpG4GXDrGzUGIeKWmk8o/AP2eo7qm9IaPf8OQGMCKeWRQ1yXGquAeq+WGWC5O+jTTCUessWAdPjEp4de0GMvK9G8TsiAUq06iSXYH64Erdkbbe39R9uPRV+F/futlh3uT3LAkKwh3wm1OMrM4mOICvFjnz8C8509AmL12g816To= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JrWWMJeC; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JrWWMJeC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E6181F000E9; Wed, 8 Jul 2026 07:51:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783497097; bh=OJHANmKsQdwywYX/0CEdvcwYSI8WhfS0TBSkz/+ZIVA=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=JrWWMJeCIPfuWaRQJgmV6c/Wr7w9QdTKRfcgh3AMqT66FTXnmQ7xiqVXdH3WYta1q UIeRkFOsFi7tipM8vJJng/Vq/vU72r2hBfdXmaFsH90jdpllMATXFjJ89HipX2Ho8D I6GPQhZwhNrWvg2XRxVmksec+d1Ttp6YP8/8I1hmCatmL7/tA1pR6RtXi2yqDX6Qm/ ge7pQ0E0G4fp1plnuj+GcZ0rnlwx7D0nafKZouvqHXSFCcRQNHhPmZ27/TeyUr3gl7 ku+ByKMCud3F7pwrweb6x5U9jspxfUYNcJkyzlQAkMRTSZ67fqwI3i4j/HJfWFMqzY 08a3wXsVwf2rQ== Message-ID: <5430b52d-a072-41ea-ab56-9bb2f6f88849@kernel.org> Date: Wed, 8 Jul 2026 09:51:34 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: test_bitmap fails on ppc/ppc64 on kernels v7.1.3, v7.2-rc2 To: Andy Shevchenko , Erhard Furtner Cc: "linuxppc-dev@lists.ozlabs.org" , linux-kernel@vger.kernel.org References: <98d65de7-e5aa-4197-85bd-219eab01e572@kernel.org> Content-Language: fr-FR From: "Christophe Leroy (CS GROUP)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 08/07/2026 à 09:43, Andy Shevchenko a écrit : > 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 >> 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 >> Signed-off-by: Yury Norov >> >> 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! > > The following change fixes the issue for me: diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c index 69813c10e6c0b..448c3eb48a4a8 100644 --- a/lib/test_bitmap.c +++ b/lib/test_bitmap.c @@ -392,6 +392,7 @@ static void __init test_bitmap_sg(void) /* Scatter/gather relationship */ bitmap_zero(bmap_tmp, 100); + bitmap_zero(bmap_res, 100); bitmap_gather(bmap_tmp, bmap_scatter, sg_mask, nbits); bitmap_scatter(bmap_res, bmap_tmp, sg_mask, nbits); expect_eq_bitmap(bmap_scatter, bmap_res, 100); Christophe