linux-kernel-mentees.lists.linuxfoundation.org archive mirror
 help / color / mirror / Atom feed
From: Himadri Pandya <himadrispandya@gmail.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: syzkaller <syzkaller@googlegroups.com>,
	linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [Linux-kernel-mentees] Question regarding marking bugs as "invalid"
Date: Tue, 15 Sep 2020 19:45:46 +0530	[thread overview]
Message-ID: <CAOY-YV=Mfu2at2KzoGNszKSEyUpTHzBdbr-SjyVyE_BJBbw_uw@mail.gmail.com> (raw)
In-Reply-To: <CACT4Y+Yo_m9C1t7AHpVq+5E-RDejMQYpK2eZUk1JTTwo+Lf3-Q@mail.gmail.com>

On Tue, Sep 15, 2020 at 6:57 PM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Tue, Sep 15, 2020 at 3:23 PM Himadri Pandya <himadrispandya@gmail.com> wrote:
> > > > > Hi,
> > > > >
> > > > > Is it correct to mark bugs as "invalid" if they have reproducers but
> > > > > the reproducer doesn't trigger any issue on testing current status? If
> > > > > not, then what should be done about such bugs?
> > > > >
> > > > > Thanks & Regards,
> > > > > Himadri
> > > > >
> > > >
> > > > Himadri,
> > > >
> > > > if possible try to determine which commit fixed the issue the
> > > > reproducer triggered.
> > > >
> > > > You can potentially bisect with the reproducer on the git history or
> > > > you can simply look in the git log of the affected files if someone
> > > > mentioned fixing something related to the trigger.
> > > >
> > > > That helps to make sure we do not just close reproducers that just
> > > > need a lot of time, configuration or luck to hit a certain crash.
> > >
> > >
> > > Hi Himadri,
> > >
> > > Basically what Lukas said.
> > > Bulk closing all of them as "invalid" would be bad for several
> > > reasons. Either do some reasonable amount of degging, or wait for
> > > syzbot fix bisection, maybe it will shed some light. It should happen
> > > after 30 days since last crash IIRC. Also all testing requests/results
> > > are shown on the dashboard, so this bit of information is not lost.
> >
> > Understood.
> >
> > I incorrectly assumed(before posting this question) that I should mark
> > such bugs as invalid and sent the command to syzbot for one such bug.
> > Now I understand that it was not the right thing. It doesn't show on
> > the dashboard and I don't know how to undo it :(.
> >
> > Bug's dashboard link -
> > https://syzkaller.appspot.com/bug?id=4c7fd5b46451d957a3d8188f393f1982f9753fe7
>
> Hi Himadri,
>
> Transitions to terminal states are not undo-able. Consider the same
> bug is rediscovered concurrently with one undoing "#syz invalid". Now
> we have 2 versions of the same bug and it will be an incomprehensible
> mess.
>

Understood. My sincerest apologies for being naive.

My assumption was that commands like "invalid" are similar to the
action of submitting a patch, it would generate some discussion about
the bug and if it is really invalid, someone with authority(like
maintainers) would actually go and mark it as "invalid". I was clearly
mistaken. But if we don't have any gatekeeping on such commands and
anyone can directly change the status of the bug by merely sending an
email to syzbot, isn't it a security issue?

Himadri

> But marking one bug in such a way is not the end of the world. We have
> other real bugs marked as invalid. So no worries.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

  reply	other threads:[~2020-09-15 14:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 11:52 [Linux-kernel-mentees] Question regarding marking bugs as "invalid" Himadri Pandya
2020-09-15 12:03 ` Lukas Bulwahn
2020-09-15 12:42   ` Dmitry Vyukov via Linux-kernel-mentees
2020-09-15 13:22     ` Himadri Pandya
2020-09-15 13:27       ` Dmitry Vyukov via Linux-kernel-mentees
2020-09-15 14:15         ` Himadri Pandya [this message]
2020-09-16  6:01           ` Dmitry Vyukov via Linux-kernel-mentees
2020-09-16  7:23             ` Lukas Bulwahn
2020-09-15 13:13   ` Himadri Pandya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOY-YV=Mfu2at2KzoGNszKSEyUpTHzBdbr-SjyVyE_BJBbw_uw@mail.gmail.com' \
    --to=himadrispandya@gmail.com \
    --cc=dvyukov@google.com \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=syzkaller@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).