Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp673779pxb; Tue, 5 Apr 2022 18:13:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyoQkQkVLnSanINLmR2p0uDs12sviJkLPo6RetMZfk4jsa62t5Frj9N3bFyvj0MO0YLvEQ8 X-Received: by 2002:a05:6a00:2484:b0:4fa:997e:3290 with SMTP id c4-20020a056a00248400b004fa997e3290mr6278229pfv.37.1649207631668; Tue, 05 Apr 2022 18:13:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649207631; cv=none; d=google.com; s=arc-20160816; b=XClnuCNZ2+62NjNncnFCsCJuoB5f5vmSuMeisuwN3wvq5NHFFeFz3hYToyDP1X+CaV bEB8easpxgXJFMNPh17oyw6wRiBUiTkkN6rfeESMObXcdD9EUsF1zAC4475eKOIukDbc G8JhRkR008wRpnrfmlfOyHLXb1VblKpVWCu3rcB+eTvNiQRF2rH9V7Ynga3+Iom1BOvO 3asm26J59ti4wWhaD+SR+FMI1KyBcGJOPgCsqRNX4X6s7JLG/aYcXcS8/JgXzFVdbrJf J6qSwF0TlHkksJRjZwxsfPHLkZb5HDJmOTAVWjM9yJ/2Xotq0x0uYspbEHePllglwvi+ F8Ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=yGsXohVt/pzhBnPGUeXN3JhwTJ6Im10IdiNPWj51poU=; b=rKDuRaX6BXecqAZPCYmT2h5/8j3TVvZ7QgQSX4MVDY3mMBdO1oTaX1ZOGuPq+S4cOL 7S6m3oW20yb/Svg3BuzPVs7OyI2iLfLlCmumMMIgNNJm7VkAypkdn6zx1bsgexv0l3cc OzbwVvuOWGYQcHW9diGy/lMS27jmFgoZi1rHZYjSFIqguVZICuzdEygMvc7nABG+PWtm jJM6yEXwHTrNa/npUlpU7b6aYEHLzpirrVSBY254oAnQo6VnLHFqqQRZ3P+SF2gWSbmG aVbva7vVsdUJhomCpsFW7KtlUdXe80W6ZcfCx5Fg6HVK8ImrtsmGLezDDKgGz0L18LV0 IEyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@linuxfoundation.org header.s=korg header.b=KG50vT1f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v5-20020a634645000000b003989e2b01f1si14675355pgk.137.2022.04.05.18.13.35; Tue, 05 Apr 2022 18:13:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@linuxfoundation.org header.s=korg header.b=KG50vT1f; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1378343AbiDELdg (ORCPT + 99 others); Tue, 5 Apr 2022 07:33:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46598 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244540AbiDEIwY (ORCPT ); Tue, 5 Apr 2022 04:52:24 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53F97D64F4; Tue, 5 Apr 2022 01:41:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 5037CB81C6A; Tue, 5 Apr 2022 08:41:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0C58C385A0; Tue, 5 Apr 2022 08:41:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649148075; bh=G/l9aUJULJwmI7YT0KaZ81Zov+Y/RRth+XG3A6aSc6U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KG50vT1f4NFFCHup4nFL157LAtUIxSeWsvxj1YVCciIhAz4YUn7K0ruaP0cFdOQ8+ CTYzSBW43WpsBAx6hrnnY2ereV7EJ4hZcv3YeqBoNLHsQI5aCmVxytCEKaGuATfaxw YF7OwY/fvccEdmWd/wTyyru9GtlPGgbCITdsKITQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christoph Anton Mitterer , David Sterba , ree.com@vger.kernel.org Subject: [PATCH 5.16 0182/1017] btrfs: verify the tranisd of the to-be-written dirty extent buffer Date: Tue, 5 Apr 2022 09:18:15 +0200 Message-Id: <20220405070359.640646036@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220405070354.155796697@linuxfoundation.org> References: <20220405070354.155796697@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Qu Wenruo commit 3777369ff1518b579560611a0d0c33f930154f64 upstream. [BUG] There is a bug report that a bitflip in the transid part of an extent buffer makes btrfs to reject certain tree blocks: BTRFS error (device dm-0): parent transid verify failed on 1382301696 wanted 262166 found 22 [CAUSE] Note the failed transid check, hex(262166) = 0x40016, while hex(22) = 0x16. It's an obvious bitflip. Furthermore, the reporter also confirmed the bitflip is from the hardware, so it's a real hardware caused bitflip, and such problem can not be detected by the existing tree-checker framework. As tree-checker can only verify the content inside one tree block, while generation of a tree block can only be verified against its parent. So such problem remain undetected. [FIX] Although tree-checker can not verify it at write-time, we still have a quick (but not the most accurate) way to catch such obvious corruption. Function csum_one_extent_buffer() is called before we submit metadata write. Thus it means, all the extent buffer passed in should be dirty tree blocks, and should be newer than last committed transaction. Using that we can catch the above bitflip. Although it's not a perfect solution, as if the corrupted generation is higher than the correct value, we have no way to catch it at all. Reported-by: Christoph Anton Mitterer Link: https://lore.kernel.org/linux-btrfs/2dfcbc130c55cc6fd067b93752e90bd2b079baca.camel@scientia.org/ CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/disk-io.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -441,17 +441,31 @@ static int csum_one_extent_buffer(struct else ret = btrfs_check_leaf_full(eb); - if (ret < 0) { - btrfs_print_tree(eb, 0); + if (ret < 0) + goto error; + + /* + * Also check the generation, the eb reached here must be newer than + * last committed. Or something seriously wrong happened. + */ + if (unlikely(btrfs_header_generation(eb) <= fs_info->last_trans_committed)) { + ret = -EUCLEAN; btrfs_err(fs_info, - "block=%llu write time tree block corruption detected", - eb->start); - WARN_ON(IS_ENABLED(CONFIG_BTRFS_DEBUG)); - return ret; + "block=%llu bad generation, have %llu expect > %llu", + eb->start, btrfs_header_generation(eb), + fs_info->last_trans_committed); + goto error; } write_extent_buffer(eb, result, 0, fs_info->csum_size); return 0; + +error: + btrfs_print_tree(eb, 0); + btrfs_err(fs_info, "block=%llu write time tree block corruption detected", + eb->start); + WARN_ON(IS_ENABLED(CONFIG_BTRFS_DEBUG)); + return ret; } /* Checksum all dirty extent buffers in one bio_vec */