From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f65.google.com ([209.85.218.65]:36936 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726657AbeIJXJk (ORCPT ); Mon, 10 Sep 2018 19:09:40 -0400 Received: by mail-oi0-f65.google.com with SMTP id p84-v6so42018188oic.4 for ; Mon, 10 Sep 2018 11:14:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180910165317.GA3237@infradead.org> References: <000000000000cbb35d05757f7a3a@google.com> <20180910165317.GA3237@infradead.org> From: Miklos Szeredi Date: Mon, 10 Sep 2018 20:14:20 +0200 Message-ID: Subject: Re: possible deadlock in aio_poll To: Christoph Hellwig Cc: syzbot , bcrl , linux-aio , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs , Al Viro , Andrea Arcangeli , Andrew Morton Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Sep 10, 2018 at 6:53 PM, Christoph Hellwig wrote: > On Mon, Sep 10, 2018 at 12:41:05AM -0700, syzbot wrote: >> ===================================================== >> WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected >> 4.19.0-rc2+ #229 Not tainted >> ----------------------------------------------------- >> syz-executor2/9399 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: >> 00000000126506e0 (&ctx->fd_wqh){+.+.}, at: spin_lock >> include/linux/spinlock.h:329 [inline] >> 00000000126506e0 (&ctx->fd_wqh){+.+.}, at: aio_poll+0x760/0x1420 >> fs/aio.c:1747 >> >> and this task is already holding: >> 000000002bed6bf6 (&(&ctx->ctx_lock)->rlock){..-.}, at: spin_lock_irq >> include/linux/spinlock.h:354 [inline] >> 000000002bed6bf6 (&(&ctx->ctx_lock)->rlock){..-.}, at: aio_poll+0x738/0x1420 >> fs/aio.c:1746 >> which would create a new lock dependency: >> (&(&ctx->ctx_lock)->rlock){..-.} -> (&ctx->fd_wqh){+.+.} > > ctx->fd_wqh seems to only exist in userfaultfd, which indeed seems > to do strange open coded waitqueue locking, and seems to fail to disable > irqs. Something like this should fix it: Why do pollable waitqueues need to disable interrupts generally? I don't see anything fundamental in the poll interface to force this requirement on users of that interface. Thanks, Miklos