linux-kernel - Re: INFO: rcu detected stall in ndisc_alloc

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ea2bc542-38b2-8218-9eb7-4c4a05da36ea@i-love.sakura.ne.jp>
Date:   Sun, 6 Jan 2019 22:47:19 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     syzbot <syzbot+ea7d9cb314b4ab49a18a@...kaller.appspotmail.com>,
        David Miller <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        LKML <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        Linux-MM <linux-mm@...ck.org>
Subject: Re: INFO: rcu detected stall in ndisc_alloc_skb

On 2019/01/06 22:24, Dmitry Vyukov wrote:
>> A report at 2019/01/05 10:08 from "no output from test machine (2)"
>> ( https://syzkaller.appspot.com/text?tag=CrashLog&x=1700726f400000 )
>> says that there are flood of memory allocation failure messages.
>> Since continuous memory allocation failure messages itself is not
>> recognized as a crash, we might be misunderstanding that this problem
>> is not occurring recently. It will be nice if we can run testcases
>> which are executed on bpf-next tree.
> 
> What exactly do you mean by running test cases on bpf-next tree?
> syzbot tests bpf-next, so it executes lots of test cases on that tree.
> One can also ask for patch testing on bpf-next tree to test a specific
> test case.

syzbot ran "some tests" before getting this report, but we can't find from
this report what the "some tests" are. If we could record all tests executed
in syzbot environments before getting this report, we could rerun the tests
(with manually examining where the source of memory consumption is) in local
environments.

Since syzbot is now using memcg, maybe we can test with sysctl_panic_on_oom == 1.
Any memory consumption that triggers global OOM killer could be considered as
a problem (e.g. memory leak or uncontrolled memory allocation).