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>
Interesting. 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".
