Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: [PATCH 0/2] mm: Two small fixes for recent syzbot reports
From:   Qian Cai <cai@lca.pw>
In-Reply-To: <76e8bbed-21d1-22e1-4148-5a5766652c0d@I-love.SAKURA.ne.jp>
Date:   Fri, 10 Apr 2020 10:26:23 -0400
Cc:     Dmitry Vyukov <dvyukov@google.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        Andrew Morton <akpm@linux-foundation.org>,
        Peter Xu <peterx@redhat.com>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux-MM <linux-mm@kvack.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <22DAFAC7-9F39-4042-BC79-B27963A13E3D@lca.pw>
References: <CAHk-=wjfngA7nHAsie7bW_JmKBhUyV9oV7zmDbZuchkJK3sR1w@mail.gmail.com>
 <AFD0DADD-0558-463F-B219-5F098E6C2EDF@lca.pw>
 <CAHk-=wgFn4rHZM8ttPWvdSzV3pL1nS3EDcAh+83OObObkot4-g@mail.gmail.com>
 <9C21961E-24D3-4C97-A5AB-B70451E4F952@lca.pw>
 <76e8bbed-21d1-22e1-4148-5a5766652c0d@I-love.SAKURA.ne.jp>
To:     Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Apr 10, 2020, at 9:12 AM, Tetsuo Handa =
<penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>=20
> On 2020/04/10 6:14, Qian Cai wrote:
>>=20
>>=20
>>> On Apr 9, 2020, at 2:06 PM, Linus Torvalds =
<torvalds@linux-foundation.org> wrote:
>>>=20
>>> On Thu, Apr 9, 2020 at 10:58 AM Qian Cai <cai@lca.pw> wrote:
>>>>=20
>>>> 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.
>>>=20
>>> Sure. But I'd want to be notified when something gets kicked out, so
>>> that I then know not to pull it.
>>>=20
>>> So it would reduce the exposure of patches, but it would also make
>>> sure those patches then don't make it upstream.
>>>=20
>>> Untested patches is fine - as long as nobody else has to suffer =
through them.
>>=20
>> 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.
>>=20
>=20
> 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.
>=20
>=20
>=20
> By the way...
>=20
> 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 .
>=20

I looked at those blocking bug list sent by Dmitry. I wonder =E2=80=9Cboys=
, why they
did=E2=80=99t send those out earlier to linux-next or somewhere more =
visible?=E2=80=9D 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=E2=80=99t 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=E2=80=99t set panic_on_warn. I=E2=80=99ll deal with warnings =
afterwards.

Occasionally, there are hard failures that I have to deal with right =
now. I=E2=80=99ll 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=E2=80=99t
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=E2=80=99s 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.=