On Thu, Feb 22, 2018 at 3:16 PM, Daniel Axtens <d...@axtens.net> wrote:
> Dmitry Vyukov <dvyu...@google.com> writes:
>> On Thu, Feb 22, 2018 at 2:31 PM, Daniel Axtens <d...@axtens.net> wrote:
>>> Dmitry Vyukov <dvyu...@google.com> writes:
>>>> On Thu, Feb 22, 2018 at 9:26 AM, Paolo Abeni <pab...@redhat.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>


So far syzbot does not test all patches, it only tests by an explicit
developer request (and that patch is not necessary on Patchwork yet,
e.g. it can be just a debugging patch that add more checks and debug
output and it still meant to fail).
But long term we probably would like to test all fixes for syzbot
bugs, so I will keep this in mind.
Is there any kind of push/poll api to get list of patches? Or
otherwise how are external systems are meant to know that there is
something to test?

>> 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?

More or less. It would be "syzbot\+[0-9a-f]+@syzkaller\.appspotmail\.com".

Reply via email to