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;
Subject: Re: [syzbot] unexpected kernel reboot (4)
To:     Dmitry Vyukov <dvyukov@google.com>
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>
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>
From:   Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Message-ID: <d829f5a8-95ba-1a17-c36a-21e23d382875@i-love.sakura.ne.jp>
Date:   Fri, 23 Apr 2021 01:13:03 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.9.1
MIME-Version: 1.0
In-Reply-To: <CACT4Y+ZvidVY5R4XqqW=b_j1Lbe2DnoKM2bPLgB4mS-CW10g1w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.

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.

> 
> 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.