Re: [PATCH v5 1/2] block: Add post_release() operation

["Gary Guo" <gary@garyguo.net>]

On Wed Sep 23, 2026 at 6:09 AM BST, Tetsuo Handa wrote:
> 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.
>
> But deferring __loop_clr_fd() to WQ context has a problem that there is no
> way to wait for completion of __loop_clr_fd() before the calling thread
> returns to the userspace, for there is no hook for calling flush_work().
> Despite what LO_FLAGS_AUTOCLEAR can guarantee is to clear backing device
> "eventually" after the last thread called lo_release(), abovementioned
> programs are expecting "synchronously" when a thread who is going to call
> umount() or open() as soon as returning from close() called close().
> That is an unsatisfiable expectation because the former is an objective
> behavior and the latter is a subjective dependency. Nonetheless, we need
> to try to wait for completion of __loop_clr_fd() at best-effort basis.
>
> Also, since __loop_clr_fd() calls module_put(THIS_MODULE) and there is no
> API for waiting for completion of remote thread's task work context,
> deferring __loop_clr_fd() to task work context has a problem (aside from
> task_work_add() being not exported to loadable modules) that module unload
> operation can unmap code/data segment before __loop_clr_fd() completes.
>
> Therefore, allow the loop driver to safely know completion of
> __loop_clr_fd(), by adding a hook which is called after disk->open_mutex
> is released.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> Changes in v5:
>   Since Bart Van Assche commented that post_release() is more clear
>   and more descriptive than run_todo(), renamed run_todo() back to
>   post_release(), and make it be called only if release() was called.
>
>  block/bdev.c                     | 28 +++++++++++++++++++---------
>  include/linux/blkdev.h           | 10 ++++++++++
>  rust/kernel/block/mq/gen_disk.rs |  1 +
>  3 files changed, 30 insertions(+), 9 deletions(-)
>
> 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,

Ideally we'd use

    ..pin_init::zeroed()

At the end of the struct expression to zero out all other fields instead of
manually zeroing each single field.

This is pre-existing issue though, so leaving as is is also fine.

Best,
Gary