From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794046882; b=xv9AoStXbRq9oPL76K7XL8uLcAV9L05FxqYytexoH8aQOujxGcpoepR/WoI6ba0m8k3Q tkUefT98RwVuyriT9LXYswfjnA2yDiUsxSTthYyCoDcym2FxeRegqpIRrPI5jGC9LI4Oq 75kPwvz2J1cpvE84JBS/vgawR7QFF/vAG8KBTjy4eUqCTDMrE0RL4F3TnlGC7AjmBOWNN GY/V+lb1/exWDejPAyEOJF7I0EtpynJnFKMvkTBBJgLDATmuHo8dpkr5LOQpmY54iHfmO Bqmi74SUqsZ1iL+TQ+0vOxE1rDoU61ZbVodso+AtRI5UXc/cMo+gZlMUeyz709+Kh7A== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794046882; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=p6SzIg4BdJwm94A0dRz3JlKYFf2D/d9xmbiijcGvCh0=; b=MHXBx0z3h4NdxJOYVWqirz48XgG2Y10lx25zHpAmt2Fwr2Km7BP2bKEw51IKyfI/ZN7P Aapq8X0WSRrb5iOvQSILWWTfbkZ0OJiZ+BP5L9u7lTI/ItbzegrGRNdHG0ODC0aNLvOFK 6fWihPw+JQUQ/E4nrRsmcnHBzVFK4Cri2NRs/F1Oy4/LvfnexhPsQa9BG/lYR/Q9KSMio Hb2g3SD+KwFc2b8h3s32Wx5uZ0/lkq19doKgjrCfFJ+OaQiYIso388Iq+EZSPblzZZndf 5nB7xzV8frkoJNHq7Jn72g+LrZ+gq3/NbEhv6bwcrv33DSEN/f6JED6MgNUHYp7Am9A== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b="Isa4FL/9"; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4EF96606EE88 for ; Sat, 7 Nov 2026 10:21:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=Isa4FL/9 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9709C1F008A1; Sat, 7 Nov 2026 10:21:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794046882; bh=p6SzIg4BdJwm94A0dRz3JlKYFf2D/d9xmbiijcGvCh0=; h=From:To:Cc:Subject:Date; b=Isa4FL/9I70/FzCUixuheIWHLsRGp/Z5CTnbZ0xcJkZsVW/QmZyeEmRRaqvW+CvbV xgfPAWEmrgkdDmYZCmsoTXyZcSwgMjCArhexc88zWRi2UE9JYrBVRLHXwfmPITAWvY rOTk4J8DtwJyZD6YEUXE2IHb3YiBQMhEs6f9DiFbQ/8E5fpSIbNzq1nyakRYPeTk32 nv026vlBAeKNngeseg/rDKY9m6UsaDbhdVZxk2pl0peH3sRcpscON0zdWRx0hhEzzZ 4nkLuP/04Te5tshwt7sZQ2m5usAsT62Qh35pFZ37GsZOrMkiM/CKy+W8y9l+ow8Fk8 G/zLNPi+UjcHQ== From: Sasha Levin To: wqu@suse.com, bartosz@fenski.pl, fdmanana@suse.com, dsterba@suse.com Cc: stable@vger.kernel.org Subject: FAILED: patch "[PATCH] btrfs: raid56: do not verify the content if there is no data checksum" failed to apply to 6.12-stable tree Date: Sat, 7 Nov 2026 05:21:20 -0500 Message-ID: <20261107052120-failed-6.12-d00b85308abe@kernel.org> X-Mailer: git-send-email 2.53.0 X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x d00b85308abee300dfb7e1ac642f38bab9ec7492 # git commit -s git send-email --to '' --in-reply-to '20261107052120-failed-6.12-d00b85308abe@kernel.org' --subject-prefix 'PATCH 6.12.y' 'HEAD^..' Thanks, Sasha ------------------ original commit in Linus's tree ------------------ >From d00b85308abee300dfb7e1ac642f38bab9ec7492 Mon Sep 17 00:00:00 2001 From: Qu Wenruo Date: Wed, 30 Sep 2026 18:29:58 +0930 Subject: [PATCH] btrfs: raid56: do not verify the content if there is no data checksum [BUG] There is a bug report that fio can fail to sync the data on a degraded RAID56 mount: # mkfs.btrfs -m raid1 -d raid5 -f $dev1 $dev2 $dev3 # mount $dev1 $mnt # btrfs balance start -d $mnt # umount $mnt # btrfs dev scan -u $dev2 # wipefs -fa $dev2 # mount -o degraded $dev1 $mnt # fio --name=degraded-write --directory=$mnt --rw=randwrite --fdatasync=4 \ --bs=4k --size=512M --randrepeat=1 The run will fail at fsync: fio: io_u error on file /mnt/btrfs/degraded-write.0.0: Input/output error: datasync offset=142254080, buflen=0 fio: pid=2064, err=5/file:io_u.c:2008, func=io_u error, error=Input/output error [CAUSE] With extra debug output, it shows the problem pretty well: rbio=2876243968 faila=0 sectornr=0 rbio=2876243968 error=0-15 csum=2 bio=15 The first line shows the rbio's full stripe logical, and stripe/sector number when verify_one_sector() failed. The second line shows more detail about the rbio, the sector range [0, 16) is corrupted, which indicates the first data stripe is corrupted, matching the missing device. The important part is that the csum bitmap shows the data csum is only for sector number 2, meanwhile the failed verification is at sector number 0. This means we did the checksum verification even if no corresponding checksum is populated. [FIX] There is already a similar check at verify_bio_data_sectors(), but unfortunately there is no such check at verify_one_sector(). Add the missing check to skip the csum verification if there is no corresponding data checksum. Reported-by: Bartosz Fenski Link: https://lore.kernel.org/linux-btrfs/a72409af-45ef-45df-9970-2e38bcb22ea6@fenski.pl/ Fixes: 7a3150723061 ("btrfs: raid56: do data csum verification during RMW cycle") CC: stable@vger.kernel.org Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba --- fs/btrfs/raid56.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c index 8ec24dbb180f9..5ec31299f1c30 100644 --- a/fs/btrfs/raid56.c +++ b/fs/btrfs/raid56.c @@ -1889,6 +1889,8 @@ static int verify_one_sector(struct btrfs_raid_bio *rbio, { struct btrfs_fs_info *fs_info = rbio->bioc->fs_info; phys_addr_t *paddrs; + const unsigned int total_sector_nr = + stripe_nr * rbio->stripe_nsectors + sector_nr; u8 csum_buf[BTRFS_CSUM_SIZE]; u8 *csum_expected; @@ -1898,6 +1900,11 @@ static int verify_one_sector(struct btrfs_raid_bio *rbio, /* No way to verify P/Q as they are not covered by data csum. */ if (stripe_nr >= rbio->nr_data) return 0; + + /* No data checksum for this sector. */ + if (!test_bit(total_sector_nr, rbio->csum_bitmap)) + return 0; + /* * If we're rebuilding a read, we have to use pages from the * bio list if possible. @@ -1908,9 +1915,7 @@ static int verify_one_sector(struct btrfs_raid_bio *rbio, paddrs = rbio_stripe_paddrs(rbio, stripe_nr, sector_nr); } - csum_expected = rbio->csum_buf + - (stripe_nr * rbio->stripe_nsectors + sector_nr) * - fs_info->csum_size; + csum_expected = rbio->csum_buf + total_sector_nr * fs_info->csum_size; calculate_block_csum_paddrs(fs_info, paddrs, csum_buf); if (unlikely(memcmp(csum_buf, csum_expected, fs_info->csum_size) != 0)) return -EIO; -- 2.53.0