From patchwork Wed Apr 26 10:51:35 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13224496 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5FC61C77B60 for ; Wed, 26 Apr 2023 10:53:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240452AbjDZKxE (ORCPT ); Wed, 26 Apr 2023 06:53:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240326AbjDZKxC (ORCPT ); Wed, 26 Apr 2023 06:53:02 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6511C46B0 for ; Wed, 26 Apr 2023 03:52:32 -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 dfw.source.kernel.org (Postfix) with ESMTPS id F15D963546 for ; Wed, 26 Apr 2023 10:51:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E827BC433EF for ; Wed, 26 Apr 2023 10:51:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682506301; bh=lLgawJq5pSVwiRUxKKxG1RE8DLXRqsKfW0RdOYdbeLc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=W1pUX1MVTciZ1f2YZjDpRalM7sPgxFJexsmPBIMrueJ0wJQvEDXqb0EC3eGsUI4rk dlBki07jwuGpiATnbKLMGaYBuyjQJZ7e1WJjZZfbnpkZ4uvnXSUAzG1VJeX+FqvPUe hjkA6q1T7eS2aEWuRIF2kIrn+a8N02Jyk4pWXim9aiQEjqc05U6IoALiY0cMMNiibD 3Lx3YgVKzpsCMeEnpxVOmJy8/jAQWcLKX4wnbrcjgad8+jkbitFbfz7F67U7cW+Tnl R5thfGK5Ik0cA8FQzfkKdCpU/bDaqYaKGSbSv2HPAe8eRFEOXKz3UHPV+Iup93RpY0 xHyN3BWYdFtvg== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 1/3] btrfs: abort transaction when sibling keys check fails for leaves Date: Wed, 26 Apr 2023 11:51:35 +0100 Message-Id: X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org From: Filipe Manana If the sibling keys check fails before we move keys from one sibling leaf to another, we are not aborting the transaction - we leave that to some higher level caller of btrfs_search_slot() (or anything else that uses it to insert items into a b+tree). This means that the transaction abort will provide a stack trace that omits the b+tree modification call chain. So change this to immediately abort the transaction and therefore get a more useful stack trace that shows us the call chain in the bt+tree modification code. It's also important to immediately abort the transaction just in case some higher level caller is not doing it, as this indicates a very serious corruption and we should stop the possibility of doing further damage. Signed-off-by: Filipe Manana Reviewed-by: Qu Wenruo --- fs/btrfs/ctree.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index d94429e0f16a..a0b97a6d075a 100644 --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c @@ -3296,6 +3296,7 @@ static int push_leaf_right(struct btrfs_trans_handle *trans, struct btrfs_root if (check_sibling_keys(left, right)) { ret = -EUCLEAN; + btrfs_abort_transaction(trans, ret); btrfs_tree_unlock(right); free_extent_buffer(right); return ret; @@ -3514,6 +3515,7 @@ static int push_leaf_left(struct btrfs_trans_handle *trans, struct btrfs_root if (check_sibling_keys(left, right)) { ret = -EUCLEAN; + btrfs_abort_transaction(trans, ret); goto out; } return __push_leaf_left(trans, path, min_data_size, empty, left, From patchwork Wed Apr 26 10:51:36 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13224498 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 891F8C77B78 for ; Wed, 26 Apr 2023 10:53:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240517AbjDZKxF (ORCPT ); Wed, 26 Apr 2023 06:53:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240494AbjDZKxD (ORCPT ); Wed, 26 Apr 2023 06:53:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7585D59C1 for ; Wed, 26 Apr 2023 03:52:33 -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 dfw.source.kernel.org (Postfix) with ESMTPS id E136A63553 for ; Wed, 26 Apr 2023 10:51:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE87FC4339C for ; Wed, 26 Apr 2023 10:51:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682506302; bh=3X/izDcmETL8JT+IcQDvivqG3Fym+01bNfen1qFVlew=; h=From:To:Subject:Date:In-Reply-To:References:From; b=jXWzuwzt4yCSPAxRkBGFWJylPfqOEshOv3OBAXM2oQcG2mzkcixToLYbilDujHD1V ULImDLL0r7PQwJ2ZjWnLK0KlKfCCSZQMbS9L0WfRYgDt2zn0o9R9HwGXvOS1mm80nj CdgK0hy54VCta1Seq0h46fUo7zdC31RsPieXwprlQhduhA30oh20Q0xbJY+2Z9vE25 0v/Zr6UJn36e1X3Q5xlFTbbc/SRojCyOHfM+2sekiP9kXSm/h6gBpN4XAEAYPuUQXf rOXElIVoRPO9MbtbRa/PnLHR6EKGn0p6hz7zGWhx8M7tDAaVjJj5Hyh1WTbxlJkuiB SzcCfqykZSLcA== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 2/3] btrfs: print extent buffers when sibling keys check fails Date: Wed, 26 Apr 2023 11:51:36 +0100 Message-Id: <14f4089a9d26606c7a15e398536ca75f9c484c9c.1682505780.git.fdmanana@suse.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org From: Filipe Manana When trying to move keys from one node/leaf to another sibling node/leaf, if the sibling keys check fails we just print an error message with the last key of the left sibling and the first key of the right sibling. However it's also useful to print all the keys of each sibling, as it may provide some clues to what went wrong, which code path may be inserting keys in an incorrect order. So just do that, print the siblings with btrfs_print_tree(), as it works for both leaves and nodes. Signed-off-by: Filipe Manana Reviewed-by: Qu Wenruo --- fs/btrfs/ctree.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index a0b97a6d075a..a061d7092369 100644 --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c @@ -2708,6 +2708,10 @@ static bool check_sibling_keys(struct extent_buffer *left, } if (btrfs_comp_cpu_keys(&left_last, &right_first) >= 0) { + btrfs_crit(left->fs_info, "left extent buffer:"); + btrfs_print_tree(left, false); + btrfs_crit(left->fs_info, "right extent buffer:"); + btrfs_print_tree(right, false); btrfs_crit(left->fs_info, "bad key order, sibling blocks, left last (%llu %u %llu) right first (%llu %u %llu)", left_last.objectid, left_last.type, From patchwork Wed Apr 26 10:51:37 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13224497 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C9D0C77B7F for ; Wed, 26 Apr 2023 10:53:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240520AbjDZKxG (ORCPT ); Wed, 26 Apr 2023 06:53:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240506AbjDZKxD (ORCPT ); Wed, 26 Apr 2023 06:53:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B7B2159D1 for ; Wed, 26 Apr 2023 03:52:33 -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 dfw.source.kernel.org (Postfix) with ESMTPS id C2DC563551 for ; Wed, 26 Apr 2023 10:51:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B540FC433EF for ; Wed, 26 Apr 2023 10:51:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1682506303; bh=uEcXpSozdvBbZ497I+QuwNthxNCOfkmSxRk/r3JMERI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CQmmGLCqy/CaAJuiCwbGTUnf5dUs20JZviiqJPz0rpfJz2za9y4igQMmVm+nREQd9 CFCxO8dgLfkE/CKz10hFEpYe3selfT/gQMDyozQOTjTSRjG+FxhG8AO+xGxGCJoocT 6pjTWUvpohMVah05cVTnpIn8k1WBCUHuEdX4m3pkcHjOtWDrqZkSYzZfgnxqfeKG3X FTX3OMWsIr8G2gTkbMEMJKw/nWdshKMok88wP5GIkpMpHu8yD6HsTZNkZP4HysI7Nf 0ssaXsCBukXwA6GctRDEu5I4MHLMdbwGl4E9/3duIivnGWJejZwChMUlH7yBLz97mU w0hTLin4q0cdg== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 3/3] btrfs: tag as unlikely the key comparison when checking sibling keys Date: Wed, 26 Apr 2023 11:51:37 +0100 Message-Id: <8e323961434327423faeea50a3c6a09ff82a364b.1682505780.git.fdmanana@suse.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org From: Filipe Manana When checking siblings keys, before moving keys from one node/leaf to a sibling node/leaf, it's very unexpected to have the last key of the left sibling greater than or equals to the first key of the right sibling, as that means we have a (serious) corruption that breaks the key ordering properties of a b+tree. Since this is unexpected, surround the comparison with the unlikely macro, which helps the compiler generate better code for the most expected case (no existing b+tree corruption). This is also what we do for other unexpected cases of invalid key ordering (like at btrfs_set_item_key_safe()). Signed-off-by: Filipe Manana Reviewed-by: Qu Wenruo --- fs/btrfs/ctree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index a061d7092369..c315fb793b30 100644 --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c @@ -2707,7 +2707,7 @@ static bool check_sibling_keys(struct extent_buffer *left, btrfs_item_key_to_cpu(right, &right_first, 0); } - if (btrfs_comp_cpu_keys(&left_last, &right_first) >= 0) { + if (unlikely(btrfs_comp_cpu_keys(&left_last, &right_first) >= 0)) { btrfs_crit(left->fs_info, "left extent buffer:"); btrfs_print_tree(left, false); btrfs_crit(left->fs_info, "right extent buffer:");