Message-ID: <87fu5thzym.fsf@linkitivity.dja.id.au>
Date:   Fri, 23 Feb 2018 01:16:17 +1100
From:   Daniel Axtens <dja@...ens.net>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Paolo Abeni <pabeni@...hat.com>,
        David Miller <davem@...emloft.net>,
        syzkaller-bugs@...glegroups.com, netdev <netdev@...r.kernel.org>,
        Florian Westphal <fw@...len.de>
Subject: Re: syzcaller patch postings...

Dmitry Vyukov <dvyukov@...gle.com> writes:

> On Thu, Feb 22, 2018 at 2:31 PM, Daniel Axtens <dja@...ens.net> wrote:
>> Dmitry Vyukov <dvyukov@...gle.com> writes:
>>
>>> On Thu, Feb 22, 2018 at 9:26 AM, Paolo Abeni <pabeni@...hat.com> wrote:
>>>> On Wed, 2018-02-21 at 16:47 -0500, David Miller wrote:
>>>>> I have to mention this now before it gets out of control.
>>>>>
>>>>> I would like to ask that syzkaller stop posting the patch it is
>>>>> testing when it posts to netdev.
>>>>
>>>> There is an open issue on this topic:
>>>>
>>>> https://github.com/google/syzkaller/issues/526
>>>>
>>>> The current behaviour is that syzbot replies to all get_maintainer.pl
>>>> recipients after testing a patch, regardless of the test submission
>>>> recipient list, the idea was instead to respect such list.
>>>
>>>
>>> Hi David, Florian, Paolo,
>>>
>>> Didn't realize it triggers patchwork. This wasn't intentional, sorry.
>>
>> A little-publicised and incorrectly-documented(!) feature of Patchwork
>> is that it supports some email headers. In particular, if you include an
>> "X-Patchwork-Hint: ignore" header, the mail will not be parsed by
>> Patchwork.
>>
>> This will stop it being recorded as a patch. Unfortunately it will also
>> stop it being recorded as a comment - I don't know if that's an issue in
>> this case. Maybe we can set you up with Patchwork 2's new checks
>> infrastructure instead.
>
> Nice. But unfortunately the current mailing technology we use allows
> very limited set of headers and no custom headers:
> https://cloud.google.com/appengine/docs/standard/go/mail/mail-with-headers-attachments
> So while possible, it would require very significant rework...

Ah, oh well, nevermind.

> What's the Patchwork 2's new checks infrastructure?

<puts on patchwork maintainer hat>
It's probably more a long-term thing than an immediate fix, but...
The checks API is designed to integrate reporting of CI/testing results
into Patchwork. It allows - through a REST API - an arbitrary process
(like your checking) to report success/warning/failure against a
patch. In your case you could report success = patch prevents bug, and
failure = bug still exists with patch. It's still slightly a
work-in-progress: at the moment you need an API key from a maintainer to
post checks. But it does look pretty in the web frontend:
e.g. https://patchwork.ozlabs.org/patch/871346/ - and the number of
successful/warning/failed tests shows up on the patch list page.

There's currently only one project (that I know of) out there that uses
the checks API - Snowpatch: https://github.com/ruscur/snowpatch

If, at any point in the future, you want to explore this, let me know as
I'd be *very* happy to help with the implementation and if needed push
features into Patchwork that make it easier/better.
</hat>

> If it will still remain a problem (hopefully not), then maybe it's
> possible to blacklist syzbot address from creating new patches. syzbot
> can do a lot, but so far does not also generate fixes for the bugs it
> discovers :)

In immediate practical terms, that might be the easiest. They all come
from the same email address, right?

Regards,
Daniel

Powered by blists - more mailing lists