All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 06/17] btrfs: push the extent lock into btrfs_run_delalloc_range
Date: Wed, 17 Apr 2024 10:35:50 -0400	[thread overview]
Message-ID: <1d2952b7fccde719e25867471e61a0126e77e3b6.1713363472.git.josef@toxicpanda.com> (raw)
In-Reply-To: <cover.1713363472.git.josef@toxicpanda.com>

We want to limit the scope of the extent lock to be around operations
that can change in flight.  Currently we hold the extent lock through
the entire writepage operation, which isn't really necessary.

We want to protect to make sure nobody has updated DELALLOC.  In
find_lock_delalloc_range we must lock the range in order to validate the
contents of our io_tree.  However once we've done that we're safe to
unlock the range and continue, as we have the page lock already held for
the range.

We are protected from all operations at this point.

* mmap() - we're holding the page lock, thus are protected.
* buffered writes - again, we're protected because we take the page lock
  for the first and last page in our range for buffered writes so we
  won't create new delalloc ranges in this area.
* direct IO - we invalidate pagecache before attempting to write a new
  area, which requires the page lock, so again are protected once we're
  holding the page lock on this range.

Additionally this behavior actually already exists for compressed, we
unlock the range as soon as we start to process the async extents, and
re-lock it during compression.  So this is completely safe, and makes
the locking more consistent.

Make this simple by just pushing the extent lock into
btrfs_run_delalloc_range.  From there followup patches will push the
lock further down into its users.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/extent_io.c | 5 ++---
 fs/btrfs/inode.c     | 5 +++++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 7b10f47d8f83..c09f46f969b1 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -396,15 +396,14 @@ noinline_for_stack bool find_lock_delalloc_range(struct inode *inode,
 	/* then test to make sure it is all still delalloc */
 	ret = test_range_bit(tree, delalloc_start, delalloc_end,
 			     EXTENT_DELALLOC, cached_state);
+
+	unlock_extent(tree, delalloc_start, delalloc_end, &cached_state);
 	if (!ret) {
-		unlock_extent(tree, delalloc_start, delalloc_end,
-			      &cached_state);
 		__unlock_for_delalloc(inode, locked_page,
 			      delalloc_start, delalloc_end);
 		cond_resched();
 		goto again;
 	}
-	free_extent_state(cached_state);
 	*start = delalloc_start;
 	*end = delalloc_end;
 out_failed:
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index ba74476ac423..2083005f2828 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2249,6 +2249,11 @@ int btrfs_run_delalloc_range(struct btrfs_inode *inode, struct page *locked_page
 	const bool zoned = btrfs_is_zoned(inode->root->fs_info);
 	int ret;
 
+	/*
+	 * We're unlocked by the different fill functions below.
+	 */
+	lock_extent(&inode->io_tree, start, end, NULL);
+
 	/*
 	 * The range must cover part of the @locked_page, or a return of 1
 	 * can confuse the caller.
-- 
2.43.0


  parent reply	other threads:[~2024-04-17 14:36 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-17 14:35 [PATCH 00/17] btrfs: restrain lock extent usage during writeback Josef Bacik
2024-04-17 14:35 ` [PATCH 01/17] btrfs: handle errors in btrfs_reloc_clone_csums properly Josef Bacik
2024-04-17 16:01   ` Johannes Thumshirn
2024-04-29 14:38   ` David Sterba
2024-04-17 14:35 ` [PATCH 02/17] btrfs: push all inline logic into cow_file_range Josef Bacik
2024-04-24 17:23   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 03/17] btrfs: unlock all the pages with successful inline extent creation Josef Bacik
2024-04-17 16:14   ` Johannes Thumshirn
2024-04-17 14:35 ` [PATCH 04/17] btrfs: move extent bit and page cleanup into cow_file_range_inline Josef Bacik
2024-04-17 16:24   ` Johannes Thumshirn
2024-04-17 14:35 ` [PATCH 05/17] btrfs: lock extent when doing inline extent in compression Josef Bacik
2024-04-17 16:29   ` Johannes Thumshirn
2024-04-19 18:52     ` Josef Bacik
2024-04-17 14:35 ` Josef Bacik [this message]
2024-04-24 17:26   ` [PATCH 06/17] btrfs: push the extent lock into btrfs_run_delalloc_range Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 07/17] btrfs: push extent lock into run_delalloc_nocow Josef Bacik
2024-04-23 11:33   ` Goldwyn Rodrigues
2024-04-23 16:49     ` Josef Bacik
2024-04-24 12:28       ` David Sterba
2024-04-24 17:53     ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 08/17] btrfs: adjust while loop condition in run_delalloc_nocow Josef Bacik
2024-04-18 14:05   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 09/17] btrfs: push extent lock down " Josef Bacik
2024-04-24 17:41   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 10/17] btrfs: remove unlock_extent from run_delalloc_compressed Josef Bacik
2024-04-24 17:43   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 11/17] btrfs: push extent lock into run_delalloc_cow Josef Bacik
2024-04-24 17:45   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 12/17] btrfs: push extent lock into cow_file_range Josef Bacik
2024-04-24 17:46   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 13/17] btrfs: push lock_extent into cow_file_range_inline Josef Bacik
2024-04-24 17:48   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 14/17] btrfs: move can_cow_file_range_inline() outside of the extent lock Josef Bacik
2024-04-23 11:38   ` Goldwyn Rodrigues
2024-04-17 14:35 ` [PATCH 15/17] btrfs: push lock_extent down in cow_file_range() Josef Bacik
2024-04-24 17:49   ` Goldwyn Rodrigues
2024-04-17 14:36 ` [PATCH 16/17] btrfs: push extent lock down in submit_one_async_extent Josef Bacik
2024-04-23 11:39   ` Goldwyn Rodrigues
2024-04-17 14:36 ` [PATCH 17/17] btrfs: add a cached state to extent_clear_unlock_delalloc Josef Bacik
2024-04-23 11:42   ` Goldwyn Rodrigues
2024-04-24 17:21   ` Goldwyn Rodrigues
2024-04-18  5:54 ` [PATCH 00/17] btrfs: restrain lock extent usage during writeback Christoph Hellwig
2024-04-18 13:45   ` Goldwyn Rodrigues
2024-04-18 14:47     ` Christoph Hellwig
2024-04-19 18:54       ` Josef Bacik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1d2952b7fccde719e25867471e61a0126e77e3b6.1713363472.git.josef@toxicpanda.com \
    --to=josef@toxicpanda.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.