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
reply other threads:[~2026-10-15 12:07 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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 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.