Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <000000000000301a4d05bfe14b8f@google.com> <CACT4Y+ZT2m7t+o9=VYCE32U_1aUVJXRp_5KgJSdEZC1YXy=qgA@mail.gmail.com>
 <CA+fCnZcWEuYeOx6-0LY+cqtGVbMx2OiyhEELErdfwaHGcUWHbQ@mail.gmail.com>
 <b8162e95-fb2e-51f6-9d9b-a4d64873876e@i-love.sakura.ne.jp>
 <abcb019f-a78a-3c6d-e199-719176a394d6@i-love.sakura.ne.jp>
 <CACT4Y+ZvidVY5R4XqqW=b_j1Lbe2DnoKM2bPLgB4mS-CW10g1w@mail.gmail.com> <d829f5a8-95ba-1a17-c36a-21e23d382875@i-love.sakura.ne.jp>
In-Reply-To: <d829f5a8-95ba-1a17-c36a-21e23d382875@i-love.sakura.ne.jp>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Thu, 22 Apr 2021 19:00:25 +0200
Message-ID: <CACT4Y+aJ510rkgq6Y3A7KK53P+1N0nPyRJ=+hZg5MYyicV4xgg@mail.gmail.com>
Subject: Re: [syzbot] unexpected kernel reboot (4)
To:     Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc:     Andrey Konovalov <andreyknvl@gmail.com>,
        syzbot <syzbot+9ce030d4c89856b27619@syzkaller.appspotmail.com>,
        LKML <linux-kernel@vger.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
        "open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
        syzkaller <syzkaller@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Apr 22, 2021 at 6:13 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2021/04/22 23:20, Dmitry Vyukov wrote:
> > I've prepared this syzkaller change:
> > https://github.com/google/syzkaller/pull/2550/files
>
> OK. Please merge and let's see whether syzkaller can find different ways.

Merge. Thanks for digging into this.

> In my environment, this problem behaves very puzzling. While the reproducer
> I use is single threaded, changing timing via CONFIG_DEBUG_KOBJECT=y or
> even https://syzkaller.appspot.com/x/patch.diff?x=13d69ffed00000 avoids
> this problem. I can't narrow down what is happening.

This:
- kill_cad_pid(SIGINT, 1);
suggests the change can help... I think... this is good.


> > Re hibernation/suspend configs, you said disabling them is not
> > helping, right? Does it still make sense to disable them?
> > If these configs are enabled, we can at least find some bugs in the
> > preparation for suspend code. However, as you noted, it will
> > immediately lead to "lost connection".
> > Ideally we somehow tweak hibernation/suspend to get to the
> > hibernation/suspend point and then immediately and automatically
> > resume.
>
> That will be one of disable-specific-functionality changes.
>
> >         This way we could test both suspend and unsuspend code, which
> > I assume can lead to bugs, and don't cause "lost connection" at the
> > same time. I guess such a mode does not exist today... and I am not
> > sure what happens with TCP connections after this.
>
> I don't know whether ssh sessions can survive 10 seconds of
> hibernation/suspend. But maybe disabling hibernation/suspend configs
> until disable-specific-functionality changes are accepted makes sense.

We would need to disable CONFIG_SUSPEND and CONFIG_HIBERNATION. I am
thinking if we will gain more than we lose... We will lose coverage of
these subsystems, but this will eliminate some of "lost connection"
crashes. Do you have any understanding as to how many "lost
connection"s this can prevent?