From patchwork Tue Jun 4 11:08:47 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13685071 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 CCD5B145339 for ; Tue, 4 Jun 2024 11:08:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499336; cv=none; b=UOa+1+Ku1zYE1fwRhQbT3atNDNfIYb4pIASMLsItLQ0XyLniSEZ6lnrNW3K5ElQZQIUdWRbRRvgBFktK1OGRYAx8O9a9/bXTXNi0k+6BojqWKgh5/zKoqqZHyTJ2aQqbenylpZxo7cghNyF0D4i3qXdvLPFgoe0LkjIpgVIuQm0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499336; c=relaxed/simple; bh=RCaNo/QBNEgLKRF4UxR7WrAayCos/eV6kpWbtoTeQOA=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=PH7qkwDVKBXvw2w6ApdJN949elOXURQjbaB4ZeJEjow/oONF/3ljLJL8NcrfZXu+T37bP2LIX2Ug63Gyknak7706WShv3EURs2GPmWWe/y8yjaSA4fBq3ToJM3ZsjGGpZXTFQD1n3JIpkqWlyn5CwRu+8Na1G2uvvgqP321mm64= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QwPsXN9W; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QwPsXN9W" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 256AFC4AF07 for ; Tue, 4 Jun 2024 11:08:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717499336; bh=RCaNo/QBNEgLKRF4UxR7WrAayCos/eV6kpWbtoTeQOA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=QwPsXN9W1Cf+hwR/cjvWfpRDPeve1bVFzTMfXjsg0te1UMeMAVIRDghdzbyIoH328 6BdfJ23Urr6Dsz3jWWInt1Afq2GFcq1A3w2RvwPWr1wSyULLp2j8VgJ5Bq+335cxGU PmkdwBA1GUNQcra5syekQSrOgcSsnAeXZvw8XqxfjFvmC5UWQd/ZUflJFb5eHRvnbP 3eHx9eoY1OkOtKrGII9up4dTcGnTDm7NAuIQQUGO4NbNPTsiuJcuAg+wZp7ZzQrrY2 28q5Rm7yrxVUvg2Ak35/yy1W0cpdM7ohViKx9/kl42bskR8iVsAkKUUp9+cy/paArg N2sljY6fsxrlQ== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 1/6] btrfs: reduce critical section at btrfs_wait_ordered_roots() Date: Tue, 4 Jun 2024 12:08:47 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Filipe Manana At btrfs_wait_ordered_roots(), there's no point in decrementing the counter after locking fs_info->ordered_root_lock as the counter is local. So change this to decrement the counter before taking the lock. Signed-off-by: Filipe Manana --- fs/btrfs/ordered-data.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c index 65d0464cd646..15428a8d4886 100644 --- a/fs/btrfs/ordered-data.c +++ b/fs/btrfs/ordered-data.c @@ -829,10 +829,10 @@ void btrfs_wait_ordered_roots(struct btrfs_fs_info *fs_info, u64 nr, done = btrfs_wait_ordered_extents(root, nr, bg); btrfs_put_root(root); - spin_lock(&fs_info->ordered_root_lock); - if (nr != U64_MAX) { + if (nr != U64_MAX) nr -= done; - } + + spin_lock(&fs_info->ordered_root_lock); } list_splice_tail(&splice, &fs_info->ordered_roots); spin_unlock(&fs_info->ordered_root_lock); From patchwork Tue Jun 4 11:08:48 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13685072 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C5D6B1459E2 for ; Tue, 4 Jun 2024 11:08:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499337; cv=none; b=tLQaBde9xVbOSszkZ7Q6mEz5Vl5JIEX3H3U4BzTwz/SL4wCIwBwHeRmlM3qWWRT07Z55EbQD0eMg6kfGqZ76R0Ys46yA+iJlyIdC+LuGZ7DpE/vRsSvnOKat4dRDUybXOW4vq7N4P6jyJ7F6+TpaZgJ1ydtPdsFDArBmpAGugqY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499337; c=relaxed/simple; bh=6jz57W78XV1MgsYGo0FhySrNR3MbmsWFHlFwlT9oRsw=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=AuoRxeei/V7ylL9j/u5uLx2nMm6001pnzItdX45Y2FW/sVORQUDqGqICznN8h9Q82kVdN02VrIl5RFu8N30nrljpgUm3yRVRzEZrQQ0yap39cg6yl0e9c65Q09aQoC3G6QUbmRMoS9x8Mu3KJ+4f8GDr/y0c7VzBQP2IJkELZxI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VE9peky4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VE9peky4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 24134C2BBFC for ; Tue, 4 Jun 2024 11:08:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717499337; bh=6jz57W78XV1MgsYGo0FhySrNR3MbmsWFHlFwlT9oRsw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VE9peky4BKDNuiXjfjB9wBIy9peN/0OZwnaCIA5t9c1XvI8p/lS+Sk0nRUG6G2Xe+ GSYb8/ClPlhcrT9ALkcNY+D6TyB4s+lvLk8yKtl6JnDO908Pk9orx7VwBwI6GftFVk 6Oyb478+6mFfJR1kgsaOmqxfJJAaOxck/uKrjX6hobec2cIRZaNIxGpKWgaGxeXRLC x31tsJBoQ8JDgGJpjEn0AYBbeGlcqhUef18gU9Flz2JQqVhV18+16VmdxoRWHc7mSF 3RXL0EdM3GpfEzYY2hn42zeqQ40iLg8P/70rKZKNyMESWwVF7rax19aLL4xunHhdcr z+lSjFUQv+9sA== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 2/6] btrfs: reduce critical section at btrfs_wait_ordered_extents() Date: Tue, 4 Jun 2024 12:08:48 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Filipe Manana At btrfs_wait_ordered_extents(), there's no point in updating the counters after locking the root's ordered extent lock, as the counters are local. So change this to update the counters before taking the lock. Signed-off-by: Filipe Manana --- fs/btrfs/ordered-data.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c index 15428a8d4886..1cabcfa85e7c 100644 --- a/fs/btrfs/ordered-data.c +++ b/fs/btrfs/ordered-data.c @@ -783,10 +783,10 @@ u64 btrfs_wait_ordered_extents(struct btrfs_root *root, u64 nr, btrfs_queue_work(fs_info->flush_workers, &ordered->flush_work); cond_resched(); - spin_lock(&root->ordered_extent_lock); if (nr != U64_MAX) nr--; count++; + spin_lock(&root->ordered_extent_lock); } list_splice_tail(&skipped, &root->ordered_extents); list_splice_tail(&splice, &root->ordered_extents); From patchwork Tue Jun 4 11:08:49 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13685073 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 1E5501459E2 for ; Tue, 4 Jun 2024 11:08:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499339; cv=none; b=G45Bu86p6gMNJ/FwhmNhNvhPhd1Ix850/0CZBjHwrAzIc/4bM9bOPztjXUPpQaImHCg0uO098sNZfSxnfOqmczJhrumzrQY4lBGVu0aicJlu2h/i58HTzKamf3n2zT8zpL2DlxcwjrN/PtWCOtx/46GZp+xNhOLtx7fH7+9YoxM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499339; c=relaxed/simple; bh=Chjy3SkgdSQsHUK2iMkDTS2biXS0HdkaxBm+CGH7rE4=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=FWAf6lPLRnmDWMrWQQKl2/C2wFUHFS04v0gNXIIuuGFJz0ZZwEhve3mb11PKRxQ/GzVlWHYlECqPJMpaoKJsAGElvO3L53znM+poUs/Ky/PdgesTszNYU3nT5EOWB0nr9qd7yjZCHUYWRgjOju+JfptKZLxfUFwyXW6ik421GrA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PXZ6Ncrv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PXZ6Ncrv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22791C32782 for ; Tue, 4 Jun 2024 11:08:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717499338; bh=Chjy3SkgdSQsHUK2iMkDTS2biXS0HdkaxBm+CGH7rE4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PXZ6Ncrvg4OA2GPHkWWMSAgKRhxaY8vBry5tXH9C2B2Ut0griQpUDBRcQDGUwc+/b Zi7+Sp7WZqAWiZiqVLNzQ7gm5LLhPPuxYLaFDboxU+X2JbVriLViDQryBgvawOp25E fi05HYQU9oHwpHfUhy7uLl4dok/OnCv2wEEEQOqe3rGjN9PK97zDedikYksykP83SR zjXSbokMbrveBGEkYjR1Xc5dVYM/yiAxRZefYyNrCto2vw6VNy9fbhu91OZ+SO8Scw /YGx84Tj3yOsnA6/AtE39mAkAnn7Ce7eFZEDzGG38XiqCY1bUgJ9PB9+9A5X4czNLg Jpo3p3xi40I2w== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 3/6] btrfs: add comment about locking to btrfs_split_ordered_extent() Date: Tue, 4 Jun 2024 12:08:49 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Filipe Manana There are subtle details about why the root's ordered_extent_lock is held, so add a comment mentioning them. Signed-off-by: Filipe Manana --- fs/btrfs/ordered-data.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c index 1cabcfa85e7c..1f7f6720b2ea 100644 --- a/fs/btrfs/ordered-data.c +++ b/fs/btrfs/ordered-data.c @@ -1247,6 +1247,23 @@ struct btrfs_ordered_extent *btrfs_split_ordered_extent( /* One ref for the tree. */ refcount_inc(&new->refs); + /* + * Take the root's ordered_extent_lock to avoid a race with + * btrfs_wait_ordered_extents() when updating the disk_bytenr and + * disk_num_bytes fields of the ordered extent below. And we disable + * IRQs because the inode's ordered_tree_lock is used in IRQ context + * elsewhere. + * + * There's no concern about a previous caller of + * btrfs_wait_ordered_extents() getting the trimmed ordered extent + * before we insert the new one, because even if it gets the ordered + * extent before it's trimmed and the new one inserted, right before it + * uses it or during its use, the ordered extent might have been + * trimmed in the meanwhile, and it missed the new ordered extent. + * There's no way around this and it's harmless for current use cases, + * so we take the root's ordered_extent_lock to fix that race during + * trimming and silence tools like KCSAN. + */ spin_lock_irq(&root->ordered_extent_lock); spin_lock(&inode->ordered_tree_lock); /* Remove from tree once */ From patchwork Tue Jun 4 11:08:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13685074 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 06B151459FA for ; Tue, 4 Jun 2024 11:08:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499340; cv=none; b=FRyS1+qJyIrSJBqTxLYObvhZzk3+tI9fhOSnORDUx1AszTR2ZyqRIlRHthbjXfTXH2+PjPc5mX9jiSw5nIcTCMf3oRDcax6zK5JUwM78+6fIQ8u3ObRCHY7v6t0Huu7y+rGpLqE87MqM7vb7iAY3uyCfrn9lRPHHPCO4KtxqHW0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499340; c=relaxed/simple; bh=cPTcmnI8U6SxzE92qGVVsAwENMn39oRjewrLheuXnRE=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=MrkQscYkG0/UE4aRw0/nVCrt/ERzGzc4DH9KEPYZ/aXMyba3i/P4JnUNbZZ5JcjArMt5WVeBae2zrVDiGIpLHBE/QP/OcrCDh+bgJk6vnEqiGqRcKS6iH6/wxr1S0oQjZaGlZQNwMjDMA1XqrLKvTp8PUBBs77GUO/+bcX7vFqA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AIvAU+gz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AIvAU+gz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2129FC4AF07 for ; Tue, 4 Jun 2024 11:08:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717499339; bh=cPTcmnI8U6SxzE92qGVVsAwENMn39oRjewrLheuXnRE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AIvAU+gzdOGrZg0cM+lYqhKrSa8iZ/da/4MOli8Pc8FATs0OhHwJMgFD0KSsUiNqA Epv9foVWz8uP4gDMyKVtRfeImeTuUT1/Ete03gAMIwr3qFqjDXM30aPYP072bC6mS4 RELh0pyOAx2vbSw56KaGTwlED5zxS7i4K5GFvoZtzPi+gdGaOlgZ4BWkBnjunwQBGs tkwLxVyUb7KGttgYowJTOI5zIuWAh9j2c3gDVg//qqyqtGZ1UWLL2ToNiXhfwxmltH 7RHen+jAGJk/zTPheODJp/JNQY3IHa2CDOODFk6emyTb6+0CV6psq2qE5Gt3fOt+OJ E7OeNt0xPV7nw== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 4/6] btrfs: avoid removal and re-insertion of split ordered extent Date: Tue, 4 Jun 2024 12:08:50 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Filipe Manana At btrfs_split_ordered_extent(), we are removing and re-inserting the ordered extent that we are trimming, but we don't need to since the trimming doesn't change its position in the red black tree because we don't have overlapping ordered extents (that would imply double allocation of extents) and we know the split length is smaller than the ordered extent's num_bytes field (we checked that early in the function). So drop the remove and re-insert code for the slit ordered extent. Signed-off-by: Filipe Manana --- fs/btrfs/ordered-data.c | 20 ++++++-------------- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c index 1f7f6720b2ea..1d7707948833 100644 --- a/fs/btrfs/ordered-data.c +++ b/fs/btrfs/ordered-data.c @@ -1266,13 +1266,13 @@ struct btrfs_ordered_extent *btrfs_split_ordered_extent( */ spin_lock_irq(&root->ordered_extent_lock); spin_lock(&inode->ordered_tree_lock); - /* Remove from tree once */ - node = &ordered->rb_node; - rb_erase(node, &inode->ordered_tree); - RB_CLEAR_NODE(node); - if (inode->ordered_tree_last == node) - inode->ordered_tree_last = NULL; + /* + * We don't have overlapping ordered extents (that would imply double + * allocation of extents) and we checked above that the split length + * does not cross the ordered extent's num_bytes field, so there's + * no need to remove it and re-insert it in the tree. + */ ordered->file_offset += len; ordered->disk_bytenr += len; ordered->num_bytes -= len; @@ -1302,14 +1302,6 @@ struct btrfs_ordered_extent *btrfs_split_ordered_extent( offset += sum->len; } - /* Re-insert the node */ - node = tree_insert(&inode->ordered_tree, ordered->file_offset, - &ordered->rb_node); - if (node) - btrfs_panic(fs_info, -EEXIST, - "zoned: inconsistency in ordered tree at offset %llu", - ordered->file_offset); - node = tree_insert(&inode->ordered_tree, new->file_offset, &new->rb_node); if (node) btrfs_panic(fs_info, -EEXIST, From patchwork Tue Jun 4 11:08:51 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13685075 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 BE58D145A0A for ; Tue, 4 Jun 2024 11:09:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499340; cv=none; b=TuKiPrOEizW3m2KTnHvG8r7W7uaJW2wswVEPYN7DgWj9KZwaHJnR1qQ/V7MEYCEGXMO9BRLyA+aHttw96XDq4M9XvMy2u8NectW2ROgk0bUZFzo4N2qu2wXtrXfcrhgERe3bi2We6f56u7/O6OsoB8PGMNZ0ifnTPrvg4VZMVds= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499340; c=relaxed/simple; bh=tWZ0MS0YS6KSsam3joOdeBOaK+riZkc7r/Qh1cW8Rk8=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=btNFuwytVm8/KT/UshiMRAvQ6bBsvou1If++1Qv39jMPXDaDQVXKqq1xR6y+d0fFmO2GM+qQ3OYDbr54abjSgvd3+TtCVpVADCAN3oE7MR4wT3S4OZjCkiIi9rjtUj1a3JlMuFMiTpRVS9CP2VG006kJYCv29i6de1oG785hVzw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=knX/2PwJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="knX/2PwJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20BF9C2BBFC for ; Tue, 4 Jun 2024 11:08:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717499340; bh=tWZ0MS0YS6KSsam3joOdeBOaK+riZkc7r/Qh1cW8Rk8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=knX/2PwJsmB5IbZ1TpnYYr4Wq9qjHxGtqtc/PyavcZIfvyD6i/ENC4ip81gR/h+ck bM7U+nFCsw0h1wxRbfFiKnvt/5nkAxJX8ogje3/bHQn3uGVsgNpS5WPShaoWXHTag8 yNzrF/fbIF3I8YooafGRXppTI5cHwF5m6AbbMm2i2M0/YlzudV+cXQmWIlTn18hufy ZVeLzRf3BBg5G7Il5cXiuNmvaeJRnu/CQwwvcK8DaHwlL6U7Gj8GH23VO3XooqRnx6 RMUnZ2WytpU6jYRc6RPOtuDnuiSJLyHKpSNmXjhI2611lftTI2rJFKwt/ReyhNa+Xr nZFDkB0FppzzQ== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 5/6] btrfs: mark ordered extent insertion failure checks as unlikely Date: Tue, 4 Jun 2024 12:08:51 +0100 Message-Id: <1d0c219fe64db06e3c8ffa7b28299fca959473e7.1717495660.git.fdmanana@suse.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Filipe Manana We never expect an ordered extent insertion to fail due to already having another ordered extent in the tree for the same file offset, since we always wait for existing ordered extents in a range to complete before writing into the range again. So mark the failure checks for the results of tree_insert() as unlikely, to make it clear it's never expected (save exceptional causes like bugs or memory corruptions) and to serve as a hint for the compiler to possibly generate better code. Signed-off-by: Filipe Manana --- fs/btrfs/ordered-data.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c index 1d7707948833..c98c8fdc14a1 100644 --- a/fs/btrfs/ordered-data.c +++ b/fs/btrfs/ordered-data.c @@ -224,7 +224,7 @@ static void insert_ordered_extent(struct btrfs_ordered_extent *entry) spin_lock_irq(&inode->ordered_tree_lock); node = tree_insert(&inode->ordered_tree, entry->file_offset, &entry->rb_node); - if (node) + if (unlikely(node)) btrfs_panic(fs_info, -EEXIST, "inconsistency in ordered tree at offset %llu", entry->file_offset); @@ -1303,7 +1303,7 @@ struct btrfs_ordered_extent *btrfs_split_ordered_extent( } node = tree_insert(&inode->ordered_tree, new->file_offset, &new->rb_node); - if (node) + if (unlikely(node)) btrfs_panic(fs_info, -EEXIST, "zoned: inconsistency in ordered tree at offset %llu", new->file_offset); From patchwork Tue Jun 4 11:08:52 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Filipe Manana X-Patchwork-Id: 13685076 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 0F85B145A0A for ; Tue, 4 Jun 2024 11:09:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499342; cv=none; b=SqGLhoVGYeoj+oVwtyo7OvAREDFOx/eQkFZbTYVyP3Vb27nJl3ryCRpyLFhKB4ksVAXMc5vv0E8S2G5hoOzw01BHcdfieurTPjojZJ/z0rmIuyclwgCCUUmT3yRnrRLb+9vRXUGfQb7oE6m5JO7cyf0lSJckhyn/8ch1Gzt0Z4E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1717499342; c=relaxed/simple; bh=WDlbdXQB+rtsAS1b5TyHDWvhrGK9LV0h3drAnw4p8P4=; h=From:To:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=PfAu8Rt7+PgXJGFQxbufzwyaStaIZ+KaLlXpxgYJ+2GcjQezZ52Lq8lKWwCGirax4Z43h0+6rcEGyhxXGnaQ5gbVPJFbKNhtZvrCA6ci5t9Wcm/5j6Mhx4JPc2DvB/KOnrlNPVAE5gWon7HexK4zF3dBvmyXhf0CPtYVDQmIEww= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bi3jP1cu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bi3jP1cu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1ED39C2BBFC for ; Tue, 4 Jun 2024 11:09:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717499341; bh=WDlbdXQB+rtsAS1b5TyHDWvhrGK9LV0h3drAnw4p8P4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bi3jP1cunylitEhKWpsK6qGsFansD05pz28v2cdOlNXfdCz2Zir6l2kEoO20VUcvN 3vAiZtH95HEy756VHudtITdkqq8gzxcZ7J+FnHuxCtG9copo0O4f5XQTRYX2tI2Ilx Hc6ex4hZyg6a0P9IINu5jJdG3BGADNlVW0z9WPdBAuYuDhPkCMouTme7RvRoXtxQqZ RVzfMF8GqPDMsq/eLbAeOOjl6tKrC4d3wfo6+1fTZghQCtZuEJFJ026i4y/EMrM4ME Cys0a58pPatTZmKuhgcwLd/DhIZOgYzQmz5rzY8Togsq2UaNAodg9Z2yhaTQPFafUx 9k6ycsNwEZVPA== From: fdmanana@kernel.org To: linux-btrfs@vger.kernel.org Subject: [PATCH 6/6] btrfs: update panic message when splitting ordered extent Date: Tue, 4 Jun 2024 12:08:52 +0100 Message-Id: X-Mailer: git-send-email 2.34.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Filipe Manana During ordered extent splitting if we find a duplicated ordered extent when attempting to insert the new ordered extent we panic but with a message that has the "zoned:" prefix. This is because the splitting used to be exclusive for zoned filesystems, but as of commit b73a6fd1b1ef ("btrfs: split partial dio bios before submit") it can also be done for non zoned filesystems during direct IO writes. So remove the "zoned:" prefix from the message and mention the split to make it more specific and different from the panic message at insert_ordered_extent(). Signed-off-by: Filipe Manana --- fs/btrfs/ordered-data.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c index c98c8fdc14a1..a3343656e0a7 100644 --- a/fs/btrfs/ordered-data.c +++ b/fs/btrfs/ordered-data.c @@ -1305,7 +1305,7 @@ struct btrfs_ordered_extent *btrfs_split_ordered_extent( node = tree_insert(&inode->ordered_tree, new->file_offset, &new->rb_node); if (unlikely(node)) btrfs_panic(fs_info, -EEXIST, - "zoned: inconsistency in ordered tree at offset %llu", + "inconsistency in ordered tree at offset %llu after split", new->file_offset); spin_unlock(&inode->ordered_tree_lock);