archive mirror
 help / color / mirror / Atom feed
From: Dmitry Vyukov <>
To: "Eric W. Biederman" <>
Cc: "J. Bruce Fields" <>,
	Stephen Rothwell <>,
	syzbot <>,, linux-fsdevel <>,
	LKML <>,
	syzkaller-bugs <>,
	Al Viro <>
Subject: Re: general protection fault in send_sigurg_to_task
Date: Fri, 17 Aug 2018 10:26:58 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
<> wrote:
> Dmitry Vyukov <> writes:
>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <> wrote:
>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote:
>>>> syzbot has found a reproducer for the following crash on:
>>>> HEAD commit:    5ed5da74de9e Add linux-next specific files for 20180813
>>>> git tree:       linux-next
>>> I fetched linux-next but don't have 5ed5da74de9e.
>> Hi Bruce,
>> +Stephen for the disappeared linux-next commit.
>> On the dashboard link you can see that it also happened on a more
>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see
>> now in linux-next.
>>> I'm also not sure why I'm on the cc for this.
>> You've been pointed to by "./scripts/ -f fs/fcntl.c"
>> as maintainer of the file, which is the file where the crash happened.
> You need to use your reproducer to bisect and find the commit that
> caused this.  Otherwise you will continue to confuse people.
> is not a good target for automated reporting
> especially against linux-next.

Hi Eric,

We will do bisection.
But I afraid it will not give perfect attribution for a number of reasons:
 - broken build/boot which happens sometimes for prolonged periods and
prohibits bisection
 - elusive races that can't be reproduced reliably and thus bisection
can give wrong results
 - bugs introduced too long ago (e.g. author email is not even valid today)
 - reproducers triggering more than 1 bug, so base bisection commit
can actually be for another bug, or bisection can switch from one bug
to another
 - last but not least, bugs without reproducers
Bisection will add useful information to the bug report, but it will
not necessary make attribution better than it is now.

Do you have more examples where bugs were misreported? From what I see
current attrition works well. There are episodic fallouts, but well,
nothing is perfect in this world. Humans don't bisect frequently and
misreport sometimes. I think we just need to re-route bugs in such

  reply	other threads:[~2018-08-17 20:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-13 12:54 general protection fault in send_sigurg_to_task syzbot
2018-08-13 13:33 ` syzbot
2018-08-14 19:11   ` J. Bruce Fields
2018-08-14 20:50     ` Dmitry Vyukov
2018-08-15  0:11       ` Stephen Rothwell
2018-08-15 18:53         ` J. Bruce Fields
2018-08-15 20:35       ` J. Bruce Fields
2018-08-16  4:01       ` Eric W. Biederman
2018-08-17 17:26         ` Dmitry Vyukov [this message]
2018-08-17 18:22           ` Eric W. Biederman
2018-08-17 18:38             ` J. Bruce Fields
2018-08-17 18:42             ` Dmitry Vyukov

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

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