[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1Grz==fg5vqVSc3jGpzQa7AV1m_B0F7QYaVWJ0mnVu4w@mail.gmail.com>
Date: Mon, 12 Oct 2020 11:51:15 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: syzkaller <syzkaller@...glegroups.com>, rgerganov@...are.com,
syzbot <syzbot+f58fe4bb535845237057@...kaller.appspotmail.com>,
gregkh <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: general protection fault in qp_release_pages
On Mon, Oct 12, 2020 at 11:29 AM Dmitry Vyukov <dvyukov@...gle.com> wrote:
> On Mon, Oct 12, 2020 at 11:16 AM Arnd Bergmann <arnd@...db.de> wrote:
> > > There is already a recorded fix for this on the dashboard:
> >
> > Ok, good.
> >
> > > https://syzkaller.appspot.com/bug?extid=f58fe4bb535845237057
> > > VMCI: check return value of get_user_pages_fast() for errors
> >
> > Ah, I actually looked at linux-next, which included the fix. I had
> > never before looked at the dashboard, good to know where to find
> > this information.
> >
> > If this is something that happened to others as well, could the
> > email report be changed to point out bugs that are already
> > fixed in linux-next but not in mainline?
>
> When syzbot mails a report, it does not know about any fixes by definition.
>
> There is a pending feature request to notify when a fix becomes known:
> https://github.com/google/syzkaller/issues/1574
Ok, I see.
> However:
> 1. This will double the number of emails from syzbot, not sure if it
> will be welcome.
It's only doubled if you assume that all bugs get fixed, right?
Probably good to stay hopeful on that ;-)
> 2. This probably only makes sense for fixes that are auto-discovered
> in git trees. While this one came from a user email, it was just not
> sent to the same thread/recipients (the common problem of replying to
> emails you did not receive). So it would not help in this case.
> 3. There is lots of other dynamic info on the dashboard (more crashes,
> where it happens, how frequently, when started/stopped). It's not
> feasible to send an email for every update (there can be 100K
> crashes), so the dashboard needed to be looked at in some cases
> anyway.
>
> Do you see any potential improvements in this context?
I would personally prefer the extra emails here. Usually by the
time I decided to ignore a thread, getting more replies to it
doesn't bother me. I understand others may feel differently here.
Making the dashboard link more prominent, or pointing out in
the email that it can contain newer information might help,
though I probably would have missed that as well, as I tend
to look at the oops output first. This was the first time I recall
that I looked at the reproducer source, which I found very
useful, but had probably missed in the past as well.
Arnd
Powered by blists - more mailing lists