All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Christian Brauner <brauner@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>, Jens Axboe <axboe@kernel.dk>
Cc: Jan Kara <jack@suse.cz>, Denis Efremov <efremov@linux.com>,
	linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: [PATCH 1/5] block: simplify bdev_del_partition()
Date: Tue, 17 Oct 2023 20:48:19 +0200	[thread overview]
Message-ID: <20231017184823.1383356-2-hch@lst.de> (raw)
In-Reply-To: <20231017184823.1383356-1-hch@lst.de>

From: Christian Brauner <brauner@kernel.org>

BLKPG_DEL_PARTITION refuses to delete partitions that still have
openers, i.e., that has an elevated @bdev->bd_openers count. If a device
is claimed by setting @bdev->bd_holder and @bdev->bd_holder_ops
@bdev->bd_openers and @bdev->bd_holders are incremented.
@bdev->bd_openers is effectively guaranteed to be >= @bdev->bd_holders.
So as long as @bdev->bd_openers isn't zero we know that this partition
is still in active use and that there might still be @bdev->bd_holder
and @bdev->bd_holder_ops set.

The only current example is @fs_holder_ops for filesystems. But that
means bdev_mark_dead() which calls into
bdev->bd_holder_ops->mark_dead::fs_bdev_mark_dead() is a nop. As long as
there's an elevated @bdev->bd_openers count we can't delete the
partition and if there isn't an elevated @bdev->bd_openers count then
there's no @bdev->bd_holder or @bdev->bd_holder_ops.

So simply open-code what we need to do. This gets rid of one more
instance where we acquire s_umount under @disk->open_mutex.

Link: https://lore.kernel.org/r/20231016-fototermin-umriss-59f1ea6c1fe6@brauner
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 block/partitions/core.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/block/partitions/core.c b/block/partitions/core.c
index e137a87f4db0d3..b0585536b407a5 100644
--- a/block/partitions/core.c
+++ b/block/partitions/core.c
@@ -485,7 +485,18 @@ int bdev_del_partition(struct gendisk *disk, int partno)
 	if (atomic_read(&part->bd_openers))
 		goto out_unlock;
 
-	delete_partition(part);
+	/*
+	 * We verified that @part->bd_openers is zero above and so
+	 * @part->bd_holder{_ops} can't be set. And since we hold
+	 * @disk->open_mutex the device can't be claimed by anyone.
+	 *
+	 * So no need to call @part->bd_holder_ops->mark_dead() here.
+	 * Just delete the partition and invalidate it.
+	 */
+
+	remove_inode_hash(part->bd_inode);
+	invalidate_bdev(part);
+	drop_partition(part);
 	ret = 0;
 out_unlock:
 	mutex_unlock(&disk->open_mutex);
-- 
2.39.2


  reply	other threads:[~2023-10-17 18:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-17 18:48 don't take s_umount under open_mutex Christoph Hellwig
2023-10-17 18:48 ` Christoph Hellwig [this message]
2023-10-18  2:33   ` [PATCH 1/5] block: simplify bdev_del_partition() Ming Lei
2023-10-17 18:48 ` [PATCH 2/5] block: WARN_ON_ONCE() when we remove active partitions Christoph Hellwig
2023-10-18  2:36   ` Ming Lei
2023-10-19  8:31   ` Jan Kara
2023-10-17 18:48 ` [PATCH 3/5] block: move bdev_mark_dead out of disk_check_media_change Christoph Hellwig
2023-10-18  3:16   ` Ming Lei
2023-10-18  6:46     ` Christoph Hellwig
2023-10-18  9:15       ` Ming Lei
2023-10-18 12:10         ` Christoph Hellwig
2023-10-18  9:24   ` Christian Brauner
2023-10-19  5:57     ` Christoph Hellwig
2023-10-19  7:24       ` Christian Brauner
2023-10-19  8:34   ` Jan Kara
2023-10-17 18:48 ` [PATCH 4/5] block: assert that we're not holding open_mutex over blk_report_disk_dead Christoph Hellwig
2023-10-18  3:18   ` Ming Lei
2023-10-19  8:43   ` Jan Kara
2023-10-17 18:48 ` [PATCH 5/5] fs: assert that open_mutex isn't held over holder ops Christoph Hellwig
2023-10-18  9:53   ` Ming Lei
2023-10-19  8:43   ` Jan Kara
2023-10-19  9:35 ` don't take s_umount under open_mutex Christian Brauner
2023-10-19 11:27   ` Jens Axboe

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=20231017184823.1383356-2-hch@lst.de \
    --to=hch@lst.de \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=efremov@linux.com \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.