Re: general protection fault in send_sigurg_to_task

From: Dmitry Vyukov <dvyukov@google.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	syzbot <syzbot+1f371ca19b341a276761@syzkaller.appspotmail.com>,
	jlayton@kernel.org, linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: general protection fault in send_sigurg_to_task
Date: Fri, 17 Aug 2018 10:26:58 -0700	[thread overview]
Message-ID: <CACT4Y+Yjj-n5BQvZhhM41fxxm57ABP1azEnrodmjZ65VrOcoxA@mail.gmail.com> (raw)
In-Reply-To: <87o9e3gdtg.fsf@xmission.com>

On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Dmitry Vyukov <dvyukov@google.com> writes:
>
>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> 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/get_maintainer.pl -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.
>
> get_maintainer.pl 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
cases.