Re: [PATCH V2] ublk: fix deadlock when reading partition table

[Ming Lei <ming.lei@redhat.com>]

On Tue, Dec 16, 2025 at 10:57:25AM -0700, Jens Axboe wrote:
> On 12/16/25 8:03 AM, Jens Axboe wrote:
> >> The issue for ublk is actually triggered by something abnormal: submit AIO
> >> & close(ublk disk) in client application, then fput() is called when the
> >> submitted AIO is done, it will cause deferred fput handler to wq for any block
> >> IO completed from irq handler.
> > 
> > My suggested logic is something ala this in bdev_release():
> > 
> > 	if (current->flags & PF_KTHREAD) {
> > 		mutex_lock(&disk->open_mutex);
> > 	} else {
> > 		if (!mutex_trylock(&disk->open_mutex)) {
> > 			deferred_put(file);
> > 			return;
> > 		}
> > 	}
> > 
> > and that's about it.
> 
> I took a look at the bug report, and now it makes more sense to me -
> this is an aio only issue, as it does fput() from ->bi_end_io() context.
> That's pretty nasty, as you don't really know what context that might
> be, both in terms of irq/bh state, but also in terms of locks. The
> former fput() does work around.
> 
> Why isn't the fix something as simple as the below, with your comment
> added on top? I'm not aware of anyone else that would do fput off
> ->bi_end_io, so we migt as well treat the source of the issue rather
> than work around it in ublk. THAT makes a lot more sense to me.

It doesn't matter if fput is called from ->bi_end_io() directly, it can
be triggered on io-uring indirectly too, in which fput() is called from
__io_submit_flush_completions() in case of non-registerd file.


Thanks,
Ming