On Tue, 2019-02-05 at 09:12 +0100, Miklos Szeredi wrote:
Not all variants of the waitqueue interface require irqs to be disabled, and fuse has nothing whatsoever to do with irqs, so there's no sane reason to disable them.
Also, AFAICS, the fuse device does not support asynchronous IO. I just don't get what this is about...
Hi Miklos,
Could this be what happens?
aio_poll() calls vfs_poll() vfs_poll() calls fuse_dev_poll() fuse_dev_poll() calls poll_wait(file, &fiq->waitq, wait) poll_wait() calls aio_poll_queue_proc(file, &fiq->waitq, wait) aio_poll_queue_proc() stores &fiq->waitq in pt->iocb->poll.head aio_poll() calls spin_lock_irq(&ctx->ctx_lock) aio_poll() calls spin_lock(&req->head->lock) (req == &pt->iocb->poll).
I think the lockdep complaint is about the FUSE fiq->waitq lock not being IRQ-safe and about aio_poll() creating a dependency between an IRQ-safe lock (ctx->ctx_lock) and a lock that is not IRQ-safe (fiq->waitq).
Thanks,
Bart.