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

[Jens Axboe <axboe@kernel.dk>]

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.

diff --git a/fs/aio.c b/fs/aio.c
index 0a23a8c0717f..d34ae02c61c1 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1104,8 +1104,13 @@ static inline void iocb_destroy(struct aio_kiocb *iocb)
 {
 	if (iocb->ki_eventfd)
 		eventfd_ctx_put(iocb->ki_eventfd);
-	if (iocb->ki_filp)
+	if (iocb->ki_filp) {
+		unsigned long flags;
+
+		local_irq_save(flags);
 		fput(iocb->ki_filp);
+		local_irq_restore(flags);
+	}
 	percpu_ref_put(&iocb->ki_ctx->reqs);
 	kmem_cache_free(kiocb_cachep, iocb);
 }

-- 
Jens Axboe