Re: possible deadlock in send_sigio

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/11/20 3:43 AM, Dmitry Vyukov wrote:
On Thu, Jun 11, 2020 at 4:33 AM Waiman Long <longman@xxxxxxxxxx> wrote:
On 4/4/20 1:55 AM, syzbot wrote:
Hello,

syzbot found the following crash on:

HEAD commit:    bef7b2a7 Merge tag 'devicetree-for-5.7' of git://git.kerne..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15f39c5de00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=91b674b8f0368e69
dashboard link: https://syzkaller.appspot.com/bug?extid=a9fb1457d720a55d6dc5
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=1454c3b7e00000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=12a22ac7e00000

The bug was bisected to:

commit 7bc3e6e55acf065500a24621f3b313e7e5998acf
Author: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
Date:   Thu Feb 20 00:22:26 2020 +0000

      proc: Use a list of inodes to flush from proc

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=165c4acde00000
final crash:    https://syzkaller.appspot.com/x/report.txt?x=155c4acde00000
console output: https://syzkaller.appspot.com/x/log.txt?x=115c4acde00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a9fb1457d720a55d6dc5@xxxxxxxxxxxxxxxxxxxxxxxxx
Fixes: 7bc3e6e55acf ("proc: Use a list of inodes to flush from proc")

========================================================
WARNING: possible irq lock inversion dependency detected
5.6.0-syzkaller #0 Not tainted
--------------------------------------------------------
ksoftirqd/0/9 just changed the state of lock:
ffffffff898090d8 (tasklist_lock){.+.?}-{2:2}, at: send_sigio+0xa9/0x340 fs/fcntl.c:800
but this lock took another, SOFTIRQ-unsafe lock in the past:
   (&pid->wait_pidfd){+.+.}-{2:2}


and interrupts could create inverse lock ordering between them.


other info that might help us debug this:
   Possible interrupt unsafe locking scenario:

         CPU0                    CPU1
         ----                    ----
    lock(&pid->wait_pidfd);
                                 local_irq_disable();
                                 lock(tasklist_lock);
                                 lock(&pid->wait_pidfd);
    <Interrupt>
      lock(tasklist_lock);

   *** DEADLOCK ***
That is a false positive. The qrwlock has the special property that it
becomes unfair (for read lock) at interrupt context. So unless it is
taking a write lock in the interrupt context, it won't go into deadlock.
The current lockdep code does not capture the full semantics of qrwlock
leading to this false positive.
Hi Longman

Thanks for looking into this.
Now the question is: how should we change lockdep annotations to fix this bug?

There was an old lockdep patch that I think may address the issue, but was not merged at the time. I will need to dig it out and see if it can be adapted to work in the current kernel. It may take some time.

Cheers,
Longman




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux