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
Cc: Nikolay Borisov <nborisov@suse.com>
Subject: [PATCH 4/5] btrfs: fix force usage in inc_block_group_ro
Date: Fri, 10 Jan 2020 11:11:27 -0500	[thread overview]
Message-ID: <20200110161128.21710-5-josef@toxicpanda.com> (raw)
In-Reply-To: <20200110161128.21710-1-josef@toxicpanda.com>

For some reason we've translated the do_chunk_alloc that goes into
btrfs_inc_block_group_ro to force in inc_block_group_ro, but these are
two different things.

force for inc_block_group_ro is used when we are forcing the block group
read only no matter what, for example when the underlying chunk is
marked read only.  We need to not do the space check here as this block
group needs to be read only.

btrfs_inc_block_group_ro() has a do_chunk_alloc flag that indicates that
we need to pre-allocate a chunk before marking the block group read
only.  This has nothing to do with forcing, and in fact we _always_ want
to do the space check in this case, so unconditionally pass false for
force in this case.

Then fixup inc_block_group_ro to honor force as it's expected and
documented to do.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
---
 fs/btrfs/block-group.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c
index 6f564e390153..2e94e14e30ee 100644
--- a/fs/btrfs/block-group.c
+++ b/fs/btrfs/block-group.c
@@ -1190,8 +1190,15 @@ static int inc_block_group_ro(struct btrfs_block_group *cache, int force)
 	spin_lock(&sinfo->lock);
 	spin_lock(&cache->lock);
 
-	if (cache->ro) {
+	if (cache->ro || force) {
 		cache->ro++;
+
+		/*
+		 * We should only be empty if we did force here and haven't
+		 * already marked ourselves read only.
+		 */
+		if (force && list_empty(&cache->ro_list))
+			list_add_tail(&cache->ro_list, &sinfo->ro_bgs);
 		ret = 0;
 		goto out;
 	}
-- 
2.24.1


  parent reply	other threads:[~2020-01-10 16:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 16:11 [PATCH 0/5][v3] clean up how we mark block groups read only Josef Bacik
2020-01-10 16:11 ` [PATCH 1/5] btrfs: check rw_devices, not num_devices for restriping Josef Bacik
2020-01-11  9:24   ` Qu Wenruo
2020-01-14 20:56   ` David Sterba
2020-01-14 21:07     ` Josef Bacik
2020-01-16 15:59       ` David Sterba
2020-01-16 16:25         ` Josef Bacik
2020-01-10 16:11 ` [PATCH 2/5] btrfs: don't pass system_chunk into can_overcommit Josef Bacik
2020-01-14 19:56   ` David Sterba
2020-01-10 16:11 ` [PATCH 3/5] btrfs: kill min_allocable_bytes in inc_block_group_ro Josef Bacik
2020-01-10 16:11 ` Josef Bacik [this message]
2020-01-11  6:15   ` [PATCH 4/5] btrfs: fix force usage " Qu Wenruo
2020-01-10 16:11 ` [PATCH 5/5] btrfs: use btrfs_can_overcommit " 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=20200110161128.21710-5-josef@toxicpanda.com \
    --to=josef@toxicpanda.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=nborisov@suse.com \
    /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.