linux-kernel - Re: INFO: task hung in __get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+b=7Kt5iVj+jMcWwfFGmYQ5D0SpF_iaBK+pjMJLUfKFpw@mail.gmail.com>
Date:   Tue, 19 Jun 2018 16:15:42 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     syzbot <syzbot+10007d66ca02b08f0e60@...kaller.appspotmail.com>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>
Subject: Re: INFO: task hung in __get_super

On Tue, Jun 19, 2018 at 4:10 PM, Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
> On 2018/06/19 20:53, Dmitry Vyukov wrote:
>> On Tue, Jun 19, 2018 at 1:44 PM, Tetsuo Handa
>> <penguin-kernel@...ove.sakura.ne.jp> wrote:
>>> This bug report is getting no feedback, but I guess that this bug is in
>>> block or mm or locking layer rather than fs layer.
>>>
>>> NMI backtrace for this bug tends to report that sb_bread() from fill_super()
>>>  from mount_bdev() is stalling is the cause of keep holding s_umount_key for
>>> more than 120 seconds. What is strange is that NMI backtrace for this bug tends
>>> to point at rcu_read_lock()/pagecache_get_page()/radix_tree_deref_slot()/
>>> rcu_read_unlock() which is expected not to stall.
>>>
>>> Since CONFIG_RCU_CPU_STALL_TIMEOUT is set to 120 (and actually +5 due to
>>> CONFIG_PROVE_RCU=y) which is longer than CONFIG_DEFAULT_HUNG_TASK_TIMEOUT,
>>> maybe setting CONFIG_RCU_CPU_STALL_TIMEOUT to smaller values (e.g. 25) can
>>> give us some hints...
>>
>> If an rcu stall is the true root cause of this, then I guess would see
>> "rcu stall" bug too. Rcu stall is detected after 120 seconds, but task
>> hang after 120-240 seconds. So rcu stall has much higher chances to be
>> detected. Do you see the corresponding "rcu stall" bug?
>
> RCU stall is detected after 125 seconds due to CONFIG_PROVE_RCU=y
> (e.g. https://syzkaller.appspot.com/bug?id=1fac0fd91219f3f2a03d6fa7deafc95fbed79cc2 ).
>
> I didn't find the corresponding "rcu stall" bug. But it is not required
> that one RCU stall takes longer than 120 seconds.
>
> down(); // Will take 120 seconds due to multiple RCU stalls
>   rcu_read_lock():
>   do_something();
>   rcu_read_unlock(): // Took 30 seconds for unknown reason.
>   rcu_read_lock():
>   do_something();
>   rcu_read_unlock(): // Took 30 seconds for unknown reason.
>   rcu_read_lock():
>   do_something();
>   rcu_read_unlock(): // Took 30 seconds for unknown reason.
>   rcu_read_lock():
>   do_something();
>   rcu_read_unlock(): // Took 30 seconds for unknown reason.
> up();


You think this is another false positive?
Like this one https://github.com/google/syzkaller/issues/516#issuecomment-395685629
?