Re: [PATCH 0/2] mm: Two small fixes for recent syzbot reports

[Qian Cai <cai@lca.pw>]

> On Apr 10, 2020, at 9:12 AM, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
> 
> On 2020/04/10 6:14, Qian Cai wrote:
>> 
>> 
>>> On Apr 9, 2020, at 2:06 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>>> 
>>> On Thu, Apr 9, 2020 at 10:58 AM Qian Cai <cai@lca.pw> wrote:
>>>> 
>>>> Agree to make a big deal part. My point is that when kicking trees of linux-next, it also could reduce the exposure of many patches (which could be bad) to linux-next and miss valuable early testing either from robots or human.
>>> 
>>> Sure. But I'd want to be notified when something gets kicked out, so
>>> that I then know not to pull it.
>>> 
>>> So it would reduce the exposure of patches, but it would also make
>>> sure those patches then don't make it upstream.
>>> 
>>> Untested patches is fine - as long as nobody else has to suffer through them.
>> 
>> Excellent. It now very much depends on how Stephen will notify you when
>> a tree, a patchset or even a developer should be blacklisted for some time
>> to make this a success.
>> 
> 
> Since patch flow forms tree structure, I don't know whether maintainers can
> afford remembering which tree, patchset or developer should be blacklisted
> when problems come from leaf git trees.
> 
> 
> 
> By the way...
> 
> Removing problematic trees might confuse "#syz test:" request, for
> developers might ask syzbot to test proposed patches on a kernel which
> does not contain problematic trees. In lucky case, test request fails
> as patch failure or build failure. But in unlucky case, syzbot fails to
> detect that proposed patch was tested on a kernel without problematic
> trees. A bit related to https://github.com/google/syzkaller/issues/1609 .
> 

I looked at those blocking bug list sent by Dmitry. I wonder “boys, why they
did’t send those out earlier to linux-next or somewhere more visible?” because
I had dealt with most of those before, and I knew the solutions to unblock them!

Even though my testing setup is somewhat different from syzbot. I don’t do
fuzzers, and my config is only focus on mm, iommu and a few core kernel pieces
with more debugging options on, but it does bare-metal and multi-arch, there are
still lots of opportunities to help each other with dealing with blocking issues.

A few things I am doing differently with syzbot on linux-next where would help to
be run continuous without blocking most of the time are,

I don’t set panic_on_warn. I’ll deal with warnings afterwards.

Occasionally, there are hard failures that I have to deal with right now. I’ll get to
the end of it, and figured out the exact commit caused it.

In syzbot mode, the bisection (by robot) is the hard part, because if you don’t
figure out the exact commit, most of times people (CC by the bug reports) would
have no clue and will be ignored. (even if the bad commit was figured out, it is
not 100% guaranteed developers would know what’s going on but it helps
dramatically, and at least we can revert it without blocking if everything else fails).

Thus, it would be really help if syzbot (or human operators) could help bisect, even
if it could only figure out one of merge commit in linux-next is bad (where with high
accuracy) and may get those ignored less.