From: sonotri <sono7ri@gmail.com>
To: Ming Lei <tom.leiming@gmail.com>, Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
sonotri <sono7ri@gmail.com>,
stable@vger.kernel.org
Subject: [PATCH] ublk: pin module while release work is pending
Date: Thu, 15 Oct 2026 21:06:54 +0900 [thread overview]
Message-ID: <20261015120654.241354-1-sono7ri@gmail.com> (raw)
ublk_ch_release() takes a device reference and queues exit_work. The VFS
module reference held through the file operations is dropped after
->release() returns. A queued work item does not acquire its own module
reference for the callback.
Consequently, normal module removal can start while exit_work is pending or
executing. In addition to the worker callback itself, the final device put
can invoke ublk_cdev_rel(), which is also module code.
Take a module reference while ->release() is still covered by the file
operations reference and drop it only after the worker has completed its
final device put. A rearming worker retains the same reference.
Merely canceling exit_work during module exit is insufficient. The worker
is the terminal path for the device reference taken by ublk_ch_release(),
so its cancellation would strand that reference and skip the associated
cleanup.
Fixes: c5c5eb24ed61 ("ublk: avoid ublk_io_release() called after ublk char dev is closed")
Cc: stable@vger.kernel.org
Signed-off-by: sonotri <sono7ri@gmail.com>
---
drivers/block/ublk_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
index 66eb55e71..71556c34a 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -2613,6 +2613,7 @@ static void ublk_ch_release_work_fn(struct work_struct *work)
/* put the reference grabbed in ublk_ch_release() */
ublk_put_device(ub);
+ module_put(THIS_MODULE);
}
static int ublk_ch_release(struct inode *inode, struct file *filp)
@@ -2625,6 +2626,8 @@ static int ublk_ch_release(struct inode *inode, struct file *filp)
*/
ublk_get_device(ub);
+ /* Keep the worker's callback and final device release code resident. */
+ __module_get(THIS_MODULE);
INIT_DELAYED_WORK(&ub->exit_work, ublk_ch_release_work_fn);
schedule_delayed_work(&ub->exit_work, 0);
return 0;
--
2.34.1
next reply other threads:[~2026-10-15 12:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 12:06 sonotri [this message]
2026-10-16 2:17 ` [PATCH] ublk: pin module while release work is pending Ming Lei
2026-10-16 14:28 ` 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=20261015120654.241354-1-sono7ri@gmail.com \
--to=sono7ri@gmail.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tom.leiming@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox