From: Bart Van Assche <bvanassche@acm.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
Nilay Shroff <nilay@linux.ibm.com>,
Bart Van Assche <bvanassche@acm.org>,
Andreas Hindborg <a.hindborg@kernel.org>,
Miguel Ojeda <ojeda@kernel.org>, Gary Guo <gary@garyguo.net>,
Tamir Duberstein <tamird@kernel.org>,
Haoze Xie <royenheart@gmail.com>, Ke Sun <sunke@kylinos.cn>
Subject: [PATCH v2 1/2] block: Add post_release() operation
Date: Thu, 17 Sep 2026 14:20:25 -0700 [thread overview]
Message-ID: <72661d0de27da8c843faf18f9b79442b0e1bb6b5.1789680010.git.bvanassche@acm.org> (raw)
In-Reply-To: <cover.1789679858.git.bvanassche@acm.org>
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Add post_release() block device operation which provides a hook for
performing synchronous cleanup without disk->open_mutex held, which is
needed by the loop devices.
Real-world container engines, test suites, and system utilities rely on
fput() from __loop_clr_fd() being completed when lo_release() returns.
But changes which went to the v7.1 merge window broke an assumption that
there is no outstanding I/O when __loop_clr_fd() is called, causing NULL
pointer dereference problem in lo_rw_aio().
In order to fix this regression, we want to allow __loop_clr_fd() to flush
outstanding I/O. But calling drain_workqueue() from __loop_clr_fd() with
disk->open_mutex held causes lockdep warnings. We need a mechanism which
can flush outstanding I/O without disk->open_mutex held.
This post_release() operation may be called multiple times since multiple
threads may open the same path concurrently.
Also, this post_release() operation is called from only bdev_release()
path. This is because loop_configure() is not yet called (there is nothing
to clear) if something went wrong between an initialization lo_open() and
an error-unwinding lo_release() within the bdev_open() path.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
[ bvanassche: changed bdev->bd_disk into disk and removed those references
to loop driver internals that are no longer correct ]
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
block/bdev.c | 3 +++
include/linux/blkdev.h | 8 ++++++++
rust/kernel/block/mq/gen_disk.rs | 1 +
3 files changed, 12 insertions(+)
diff --git a/block/bdev.c b/block/bdev.c
index fac74319e9fb..350f3c29d682 100644
--- a/block/bdev.c
+++ b/block/bdev.c
@@ -1189,6 +1189,9 @@ void bdev_release(struct file *bdev_file)
blkdev_put_whole(bdev);
mutex_unlock(&disk->open_mutex);
+ if (disk->fops->post_release)
+ disk->fops->post_release(disk);
+
module_put(disk->fops->owner);
put_no_open:
blkdev_put_no_open(bdev);
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d003a9d2d1f6..5f51fe0d8bcc 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1580,6 +1580,14 @@ struct block_device_operations {
unsigned int flags);
int (*open)(struct gendisk *disk, blk_mode_t mode);
void (*release)(struct gendisk *disk);
+ /*
+ * This operation is called after returned from release() and
+ * disk->open_mutex was released. But this operation is not called
+ * after an initialization open() has succeeded but something went
+ * wrong and an error-unwinding release() was called.
+ * This operation might sleep and has to be idempotent.
+ */
+ void (*post_release)(struct gendisk *disk);
int (*ioctl)(struct block_device *bdev, blk_mode_t mode,
unsigned cmd, unsigned long arg);
int (*compat_ioctl)(struct block_device *bdev, blk_mode_t mode,
diff --git a/rust/kernel/block/mq/gen_disk.rs b/rust/kernel/block/mq/gen_disk.rs
index fc97dd873974..2ff77ef49781 100644
--- a/rust/kernel/block/mq/gen_disk.rs
+++ b/rust/kernel/block/mq/gen_disk.rs
@@ -129,6 +129,7 @@ pub fn build<T: Operations>(
submit_bio: None,
open: None,
release: None,
+ post_release: None,
ioctl: None,
compat_ioctl: None,
check_events: None,
next prev parent reply other threads:[~2026-09-17 21:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 21:20 [PATCH v2 0/2] loop: Fix teardown Bart Van Assche
2026-09-17 21:20 ` Bart Van Assche [this message]
2026-09-17 21:20 ` [PATCH v2 2/2] loop: Perform __loop_clr_fd() after disk->open_mutex is dropped Bart Van Assche
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=72661d0de27da8c843faf18f9b79442b0e1bb6b5.1789680010.git.bvanassche@acm.org \
--to=bvanassche@acm.org \
--cc=a.hindborg@kernel.org \
--cc=axboe@kernel.dk \
--cc=gary@garyguo.net \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=nilay@linux.ibm.com \
--cc=ojeda@kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=royenheart@gmail.com \
--cc=sunke@kylinos.cn \
--cc=tamird@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox