[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+aOL7O_bzr9La_eTK8=HezT1YX4SOyE_dO3_eFMThhDdg@mail.gmail.com>
Date: Tue, 16 Jan 2018 19:01:58 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Pavel Machek <pavel@....cz>, Mike Galbraith <efault@....de>,
LKML <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
syzkaller <syzkaller@...glegroups.com>
Subject: Re: LKML admins (syzbot emails are not delivered)
On Mon, Jan 15, 2018 at 5:16 PM, Eric W. Biederman
<ebiederm@...ssion.com> wrote:
> Dmitry Vyukov <dvyukov@...gle.com> writes:
>
> 2> On Mon, Jan 15, 2018 at 1:54 PM, Pavel Machek <pavel@....cz> wrote:
>>> Hi!
>>>
>>>> > *Snort*
>>>> >
>>>> > If the information to solve an issue is not in the Oops syzbot is
>>>> > useless.
>>>>
>>>> Hi Eric
>>>>
>>>> That's true. But maintainers of the subsystem is in the best position
>>>> to judge that. For that they need to see the report.
>>>
>>> Unless they are already overloaded by better quality reports.
>>>
>>>> > Further there is no place in the syzbot process to test fixes.
>>>>
>>>> Please elaborate.
>>>> Kernel developer who fixes the bugs, tests it the same way as he/she
>>>> does for any other bugs. There is really nothing in syzbot that
>>>> prevents you from testing.
>>>
>>> Well, normally people are interested in the bugs they report, and thus
>>> willing to test the patches. Your bot.. is not interested.
>>
>> Not true. syzbot is very much interested in bugs it reports, keeps
>> careful track of them and tests patches.
>
> It offers to test fixes not to add more information so that the bug can
> be tracked down better. Having asked explicitly for some additional
> testing to track down and issue and been told the process was happy to
> test fixes I know that this has been most definitely the case.
>
> Modifying the kernel and testing is important as sometimes it can be
> extremely difficult to figure out what causes an issue. Especially when
> it is an interaction of factors like running a system on the edge of
> OOM. So it requires small kmallocs to fail (which does not usually
> happen).
Patch testing can be used for debugging as well. It just runs your
patch (maybe with additional WARNINGs) and then gives you console
output if kernel crashes. I've clarified docs regarding this:
https://github.com/google/syzkaller/commit/9aaf64b3742d1d4f744e22cad567906cebb201a2
9 out of 10 of these bugs can also be reproduced locally without any
special setup other than using the provided config.
Powered by blists - more mailing lists