Message ID | bb5dfd55ea2026303ab2296f4a6df3da7dd64006.1674217480.git.linux@leemhuis.info |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp172770wrn; Fri, 20 Jan 2023 04:36:34 -0800 (PST) X-Google-Smtp-Source: AMrXdXu93gyODm9ABAjQAo6L2PMLpnfqjFYfflOriyilXER84uziIbQeXvmbqHidpjXAVm46JYv3 X-Received: by 2002:a17:907:d23:b0:877:6873:70b9 with SMTP id gn35-20020a1709070d2300b00877687370b9mr10568765ejc.29.1674218194014; Fri, 20 Jan 2023 04:36:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674218193; cv=none; d=google.com; s=arc-20160816; b=BTKBgWgTVRLoeOQ9meXvQViY3lxDcHikzH6vkmet+1Aj9OfEg4rWbT7KgU76l3sD1G jZJQ0xF1UWKjpkCDI+bTG9ubMEuWLwGSXtgo9fy4MAFA98rn/97iuByPAnSijIzViwdX 18vnJJwy9k7rWpMVW0uIzWWz/P8csK5OF5sFddE26RV5ZHf9FWXfzYE1CuISK4PC8jv+ T/6VQhJWe0Az/kRhRONuC9NddAG77gTzR9kijUwaT+ERYoqDgmCwGud+5RsDIHZrXvT0 K2azZ8a9UpLZf8hSxEf6senDtF4/mXHyxBn7OtJFGqHJ+P5d1d+/wV/4Mnlk4ky+YRmK rxiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=dXuijO9OGp8Vq/sfQ7Lfn8QrWAQCMKhSoueRZJRzGAU=; b=Kbchjqo34QcAXqP76lIUxNlncw4Cr+Bbu5PWsjcrZ5I2PckSnjM0FzpRhu3kjEBdx6 ofaf97292jhQCs9IzwtyzmzRWHv15opCss0/wpc/Z4bT22tVrHbu+Dz6luvsvHxyzJgp u/9bb237Ezf3d90BQnuXp5ACmqcned177zIsTFMw7d/trB8Pf4Fe2uqK+DZYV3kqyFTC 8VfFvvmj5Fp7i+TuQVrXBP90ZQ9CXcVHAuMjRnTJchGpoZqgKdZAVv0v9brDD2n5tLGq WpMsymJcd/XtUVAmCX/Q0W7MDB/1qfI4MTI6tygrchesLfcniVNIGHLiFMrml3RZNeQ+ +4zg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dd7-20020a1709069b8700b007ad9c8201e7si22899558ejc.93.2023.01.20.04.36.09; Fri, 20 Jan 2023 04:36:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230209AbjATMfj (ORCPT <rfc822;literming00@gmail.com> + 99 others); Fri, 20 Jan 2023 07:35:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58568 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230147AbjATMf3 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 20 Jan 2023 07:35:29 -0500 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [80.237.130.52]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1410DBD17B for <linux-kernel@vger.kernel.org>; Fri, 20 Jan 2023 04:35:24 -0800 (PST) Received: from ip4d14bd73.dynamic.kabel-deutschland.de ([77.20.189.115] helo=truhe.fritz.box); authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1pIqc6-0007pV-Ds; Fri, 20 Jan 2023 13:35:22 +0100 From: Thorsten Leemhuis <linux@leemhuis.info> To: Joe Perches <joe@perches.com>, Andy Whitcroft <apw@canonical.com>, Dwaipayan Ray <dwaipayanray1@gmail.com>, Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: =?utf-8?q?Kai_Wasserb=C3=A4ch?= <kai@dev.carbon-project.org>, Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org Subject: [PATCH v4 2/3] checkpatch: warn when Reported-by: is not followed by Link: Date: Fri, 20 Jan 2023 13:35:19 +0100 Message-Id: <bb5dfd55ea2026303ab2296f4a6df3da7dd64006.1674217480.git.linux@leemhuis.info> X-Mailer: git-send-email 2.39.0 In-Reply-To: <cover.1674217480.git.linux@leemhuis.info> References: <cover.1674217480.git.linux@leemhuis.info> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de;linux@leemhuis.info;1674218125;93060bd7; X-HE-SMSGID: 1pIqc6-0007pV-Ds X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755545017418817748?= X-GMAIL-MSGID: =?utf-8?q?1755545017418817748?= |
Series |
checkpatch.pl: warn about discouraged tags and missing Link: tags
|
|
Commit Message
Thorsten Leemhuis
Jan. 20, 2023, 12:35 p.m. UTC
From: Kai Wasserbäch <kai@dev.carbon-project.org> Encourage patch authors to link to reports by issuing a warning, if a Reported-by: is not accompanied by a link to the report. Those links are often extremely useful for any code archaeologist that wants to know more about the backstory of a change than the commit message provides. That includes maintainers higher up in the patch-flow hierarchy, which is why Linus asks developers to add such links [1, 2, 3]. To quote [1]: > Again, the commit has a link to the patch *submission*, which is > almost entirely useless. There's no link to the actual problem the > patch fixes. > > [...] > > Put another way: I can see that > > Reported-by: Zhangfei Gao <zhangfei.gao@foxmail.com> > > in the commit, but I don't have a clue what the actual report was, and > there really isn't enough information in the commit itself, except for > a fairly handwavy "Device drivers might, for instance, still need to > flush operations.." > > I don't want to know what device drivers _might_ do. I would want to > have an actual pointer to what they do and where. Another reason why these links are wanted: the ongoing regression tracking efforts can only scale with them, as they allow the regression tracking bot 'regzbot' to automatically connect tracked reports with patches that are posted or committed to fix tracked regressions. Link: https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/ [1] Link: https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/ [2] Link: https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/ [3] Signed-off-by: Kai Wasserbäch <kai@dev.carbon-project.org> Co-developed-by: Thorsten Leemhuis <linux@leemhuis.info> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> --- scripts/checkpatch.pl | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Comments
On Fri, 20 Jan 2023 13:35:19 +0100 Thorsten Leemhuis wrote: > From: Kai Wasserbäch <kai@dev.carbon-project.org> > > Encourage patch authors to link to reports by issuing a warning, if > a Reported-by: is not accompanied by a link to the report. Those links > are often extremely useful for any code archaeologist that wants to know > more about the backstory of a change than the commit message provides. > That includes maintainers higher up in the patch-flow hierarchy, which > is why Linus asks developers to add such links [1, 2, 3]. To quote [1]: Is it okay if we exclude syzbot reports from this rule? If full syzbot report ID is provided - it's as good as a link. And regression tracking doesn't seem to happen much on syzbot reports either. I like the addition otherwise, it's already catching missing links in netdev land!
On 02.03.23 05:46, Jakub Kicinski wrote: > On Fri, 20 Jan 2023 13:35:19 +0100 Thorsten Leemhuis wrote: >> From: Kai Wasserbäch <kai@dev.carbon-project.org> >> >> Encourage patch authors to link to reports by issuing a warning, if >> a Reported-by: is not accompanied by a link to the report. Those links >> are often extremely useful for any code archaeologist that wants to know >> more about the backstory of a change than the commit message provides. >> That includes maintainers higher up in the patch-flow hierarchy, which >> is why Linus asks developers to add such links [1, 2, 3]. To quote [1]: > > Is it okay if we exclude syzbot reports from this rule? > If full syzbot report ID is provided - it's as good as a link. Hmmm. Not sure. Every special case makes things harder for humans and software that looks at a commits downstream. Clicking on a link also makes things easy for code archaeologists that might look into the issue months or years later (which might not even know how to find the report and potential discussions on lore from the syzbot report ID). Hence, wouldn't it be better to ask the syzbot folks to change their reporting slightly and suggest something like this instead in their reports (the last line is the new one): ``` IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+bba886ab504fcafecafe@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/cafecaca0cafecaca0cafecaca0@google.com/ ``` This might not be to hard if they known the message-id in advance. Maybe they could even use the syzbot report ID as msg-id to make things even easier. And for developers not much would change afaics, they just need to copy and paste two lines instead of one. > And regression tracking doesn't seem to happen much on syzbot > reports either. Yeah, right now I most of the time stay away from CI reports and leave the tracking to the people that run the CI (unless it's something I consider worth tracking), but I hope that might change over time to have things in one place. > I like the addition otherwise, it's already catching missing links > in netdev land! Thx for saying this! Ciao, Thorsten
On Thu, 2 Mar 2023 06:17:22 +0100 Thorsten Leemhuis wrote: > On 02.03.23 05:46, Jakub Kicinski wrote: > > On Fri, 20 Jan 2023 13:35:19 +0100 Thorsten Leemhuis wrote: > >> Encourage patch authors to link to reports by issuing a warning, if > >> a Reported-by: is not accompanied by a link to the report. Those links > >> are often extremely useful for any code archaeologist that wants to know > >> more about the backstory of a change than the commit message provides. > >> That includes maintainers higher up in the patch-flow hierarchy, which > >> is why Linus asks developers to add such links [1, 2, 3]. To quote [1]: > > > > Is it okay if we exclude syzbot reports from this rule? > > If full syzbot report ID is provided - it's as good as a link. > > Hmmm. Not sure. Every special case makes things harder for humans and > software that looks at a commits downstream. Clicking on a link also > makes things easy for code archaeologists that might look into the issue > months or years later (which might not even know how to find the report > and potential discussions on lore from the syzbot report ID). No other system comes close to syzbot in terms of reporting meaningful bugs, IMHO special casing it doesn't risk creep. Interestingly other bots attach links which are 100% pointless noise: Reported-by: Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4174 Oh, eh. Let's see how noisy this check is once the merge window is over. > Hence, wouldn't it be better to ask the syzbot folks to change their > reporting slightly and suggest something like this instead in their > reports (the last line is the new one): > > ``` > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+bba886ab504fcafecafe@syzkaller.appspotmail.com > Link: https://lore.kernel.org/r/cafecaca0cafecaca0cafecaca0@google.com/ > ``` > > This might not be to hard if they known the message-id in advance. Maybe > they could even use the syzbot report ID as msg-id to make things even > easier. And for developers not much would change afaics, they just need > to copy and paste two lines instead of one. Dmitry, WDYT?
On Thu, 2 Mar 2023 at 06:40, Jakub Kicinski <kuba@kernel.org> wrote: > > On Thu, 2 Mar 2023 06:17:22 +0100 Thorsten Leemhuis wrote: > > On 02.03.23 05:46, Jakub Kicinski wrote: > > > On Fri, 20 Jan 2023 13:35:19 +0100 Thorsten Leemhuis wrote: > > >> Encourage patch authors to link to reports by issuing a warning, if > > >> a Reported-by: is not accompanied by a link to the report. Those links > > >> are often extremely useful for any code archaeologist that wants to know > > >> more about the backstory of a change than the commit message provides. > > >> That includes maintainers higher up in the patch-flow hierarchy, which > > >> is why Linus asks developers to add such links [1, 2, 3]. To quote [1]: > > > > > > Is it okay if we exclude syzbot reports from this rule? > > > If full syzbot report ID is provided - it's as good as a link. > > > > Hmmm. Not sure. Every special case makes things harder for humans and > > software that looks at a commits downstream. Clicking on a link also > > makes things easy for code archaeologists that might look into the issue > > months or years later (which might not even know how to find the report > > and potential discussions on lore from the syzbot report ID). > > No other system comes close to syzbot in terms of reporting meaningful > bugs, IMHO special casing it doesn't risk creep. > > Interestingly other bots attach links which are 100% pointless noise: > > Reported-by: Abaci Robot <abaci@linux.alibaba.com> > Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4174 > > Oh, eh. Let's see how noisy this check is once the merge window is over. > > > Hence, wouldn't it be better to ask the syzbot folks to change their > > reporting slightly and suggest something like this instead in their > > reports (the last line is the new one): > > > > ``` > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+bba886ab504fcafecafe@syzkaller.appspotmail.com > > Link: https://lore.kernel.org/r/cafecaca0cafecaca0cafecaca0@google.com/ > > ``` > > > > This might not be to hard if they known the message-id in advance. Maybe > > they could even use the syzbot report ID as msg-id to make things even > > easier. And for developers not much would change afaics, they just need > > to copy and paste two lines instead of one. > > Dmitry, WDYT? Hi Jakub, Thorsten, Adding a Link to syzbot reports should be relatively trivial. Ted proposed to use Link _instead_ of Reported-by: https://github.com/google/syzkaller/issues/3596 > in fact, it might be nice if we could encourage upstream developers > put in the commit trailer: > Link: https://syzkaller.appspot.com/bug?id=5266d464285a03cee9dbfda7d2452a72c3c2ae7c > in addition to, or better yet, instead of: > Reported-by: syzbot+15cd994e273307bf5cfa@syzkaller.appspotmail.com We could also use a link in the Reported-by tag, e.g.: Reported-by: https://syzkaller.appspot.com/b/5266d464285a03cee9db Some folks parse Reported-by to collect stats. What is better?
On 02.03.23 09:27, Dmitry Vyukov wrote: > On Thu, 2 Mar 2023 at 06:40, Jakub Kicinski <kuba@kernel.org> wrote: >> On Thu, 2 Mar 2023 06:17:22 +0100 Thorsten Leemhuis wrote: >>> On 02.03.23 05:46, Jakub Kicinski wrote: >>>> On Fri, 20 Jan 2023 13:35:19 +0100 Thorsten Leemhuis wrote: >>>>> Encourage patch authors to link to reports by issuing a warning, if >>>>> a Reported-by: is not accompanied by a link to the report. Those links >>>>> are often extremely useful for any code archaeologist that wants to know >>>>> more about the backstory of a change than the commit message provides. >>>>> That includes maintainers higher up in the patch-flow hierarchy, which >>>>> is why Linus asks developers to add such links [1, 2, 3]. To quote [1]: >>>> >>>> Is it okay if we exclude syzbot reports from this rule? >>>> If full syzbot report ID is provided - it's as good as a link. >>> >>> Hmmm. Not sure. Every special case makes things harder for humans and >>> software that looks at a commits downstream. Clicking on a link also >>> makes things easy for code archaeologists that might look into the issue >>> months or years later (which might not even know how to find the report >>> and potential discussions on lore from the syzbot report ID). >> >> No other system comes close to syzbot in terms of reporting meaningful >> bugs, IMHO special casing it doesn't risk creep. >> >> Interestingly other bots attach links which are 100% pointless noise: >> >> Reported-by: Abaci Robot <abaci@linux.alibaba.com> >> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4174 >> >> Oh, eh. Let's see how noisy this check is once the merge window is over. >> >>> Hence, wouldn't it be better to ask the syzbot folks to change their >>> reporting slightly and suggest something like this instead in their >>> reports (the last line is the new one): >>> >>> ``` >>> IMPORTANT: if you fix the issue, please add the following tag to the commit: >>> Reported-by: syzbot+bba886ab504fcafecafe@syzkaller.appspotmail.com >>> Link: https://lore.kernel.org/r/cafecaca0cafecaca0cafecaca0@google.com/ >>> ``` >>> >>> This might not be to hard if they known the message-id in advance. Maybe >>> they could even use the syzbot report ID as msg-id to make things even >>> easier. And for developers not much would change afaics, they just need >>> to copy and paste two lines instead of one. >> >> Dmitry, WDYT? > > Adding a Link to syzbot reports should be relatively trivial. Sounds good. > Ted proposed to use Link _instead_ of Reported-by: > https://github.com/google/syzkaller/issues/3596 >> in fact, it might be nice if we could encourage upstream developers >> put in the commit trailer: >> Link: https://syzkaller.appspot.com/bug?id=5266d464285a03cee9dbfda7d2452a72c3c2ae7c >> in addition to, or better yet, instead of: >> Reported-by: syzbot+15cd994e273307bf5cfa@syzkaller.appspotmail.com > > We could also use a link in the Reported-by tag, e.g.: > > Reported-by: https://syzkaller.appspot.com/b/5266d464285a03cee9db > > Some folks parse Reported-by to collect stats. > > What is better? Here are my thoughts: * we should definitely have a "Link:" to the report in lore, as that's the long-term archive under our own control and also where discussions happen after the report was posted; but I'm biased here, as such a tag would make tracking with regzbot a no-brainer ;) * "Reported-by:" IMHO should stay for the hat tip and stats aspects; I don't care if it includes the syzbot report ID or not (omitting it might be good for the stats aspects and is more friendly to the eyes, but those are just details) * a Link: to the syzkaller web ui might be nice, too -- and likely is the easiest thing to look out for on the syzbot server side IOW something like this maybe: Reported-by: syzbot+cafecafecaca0cafecafe@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/cafecafecaca0cafecafe@google.com/ Link: https://syzkaller.appspot.com/b/cafecafecaca0cafecafe Something like the following would look more normal, but of course is only possible if syzbot starts out to look for such Link: tags (not sure if the msgid is valid here, but you get the idea): Reported-by: syzbot@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/syzbot+cafecafecaca0cafecafe-syzkaller-appspotmail-com@google.com/ Ciao, Thorsten
On Thu, 2 Mar 2023 at 10:04, Thorsten Leemhuis <linux@leemhuis.info> wrote: > > On 02.03.23 09:27, Dmitry Vyukov wrote: > > On Thu, 2 Mar 2023 at 06:40, Jakub Kicinski <kuba@kernel.org> wrote: > >> On Thu, 2 Mar 2023 06:17:22 +0100 Thorsten Leemhuis wrote: > >>> On 02.03.23 05:46, Jakub Kicinski wrote: > >>>> On Fri, 20 Jan 2023 13:35:19 +0100 Thorsten Leemhuis wrote: > >>>>> Encourage patch authors to link to reports by issuing a warning, if > >>>>> a Reported-by: is not accompanied by a link to the report. Those links > >>>>> are often extremely useful for any code archaeologist that wants to know > >>>>> more about the backstory of a change than the commit message provides. > >>>>> That includes maintainers higher up in the patch-flow hierarchy, which > >>>>> is why Linus asks developers to add such links [1, 2, 3]. To quote [1]: > >>>> > >>>> Is it okay if we exclude syzbot reports from this rule? > >>>> If full syzbot report ID is provided - it's as good as a link. > >>> > >>> Hmmm. Not sure. Every special case makes things harder for humans and > >>> software that looks at a commits downstream. Clicking on a link also > >>> makes things easy for code archaeologists that might look into the issue > >>> months or years later (which might not even know how to find the report > >>> and potential discussions on lore from the syzbot report ID). > >> > >> No other system comes close to syzbot in terms of reporting meaningful > >> bugs, IMHO special casing it doesn't risk creep. > >> > >> Interestingly other bots attach links which are 100% pointless noise: > >> > >> Reported-by: Abaci Robot <abaci@linux.alibaba.com> > >> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4174 > >> > >> Oh, eh. Let's see how noisy this check is once the merge window is over. > >> > >>> Hence, wouldn't it be better to ask the syzbot folks to change their > >>> reporting slightly and suggest something like this instead in their > >>> reports (the last line is the new one): > >>> > >>> ``` > >>> IMPORTANT: if you fix the issue, please add the following tag to the commit: > >>> Reported-by: syzbot+bba886ab504fcafecafe@syzkaller.appspotmail.com > >>> Link: https://lore.kernel.org/r/cafecaca0cafecaca0cafecaca0@google.com/ > >>> ``` > >>> > >>> This might not be to hard if they known the message-id in advance. Maybe > >>> they could even use the syzbot report ID as msg-id to make things even > >>> easier. And for developers not much would change afaics, they just need > >>> to copy and paste two lines instead of one. > >> > >> Dmitry, WDYT? > > > > Adding a Link to syzbot reports should be relatively trivial. > > Sounds good. > > > Ted proposed to use Link _instead_ of Reported-by: > > https://github.com/google/syzkaller/issues/3596 > >> in fact, it might be nice if we could encourage upstream developers > >> put in the commit trailer: > >> Link: https://syzkaller.appspot.com/bug?id=5266d464285a03cee9dbfda7d2452a72c3c2ae7c > >> in addition to, or better yet, instead of: > >> Reported-by: syzbot+15cd994e273307bf5cfa@syzkaller.appspotmail.com > > > > We could also use a link in the Reported-by tag, e.g.: > > > > Reported-by: https://syzkaller.appspot.com/b/5266d464285a03cee9db > > > > Some folks parse Reported-by to collect stats. > > > > What is better? > > Here are my thoughts: > > * we should definitely have a "Link:" to the report in lore, as that's > the long-term archive under our own control and also where discussions > happen after the report was posted; but I'm biased here, as such a tag > would make tracking with regzbot a no-brainer ;) > > * "Reported-by:" IMHO should stay for the hat tip and stats aspects; I > don't care if it includes the syzbot report ID or not (omitting it might > be good for the stats aspects and is more friendly to the eyes, but > those are just details) > > * a Link: to the syzkaller web ui might be nice, too -- and likely is > the easiest thing to look out for on the syzbot server side > > IOW something like this maybe: > > Reported-by: syzbot+cafecafecaca0cafecafe@syzkaller.appspotmail.com > Link: https://lore.kernel.org/r/cafecafecaca0cafecafe@google.com/ > Link: https://syzkaller.appspot.com/b/cafecafecaca0cafecafe > > Something like the following would look more normal, but of course is > only possible if syzbot starts out to look for such Link: tags (not sure > if the msgid is valid here, but you get the idea): > > Reported-by: syzbot@syzkaller.appspotmail.com > Link: > https://lore.kernel.org/r/syzbot+cafecafecaca0cafecafe-syzkaller-appspotmail-com@google.com/ Oh, you mean lore link. We can parse out our hash from any tag, but the problem is that the current email api we use, does not allow to specify Message-ID before sending, so we don't know it when generating the text. We don't even know it after sending, the API is super simple: https://pkg.go.dev/google.golang.org/appengine/mail So we don't know what the lore link will be...
On 02.03.23 10:11, Dmitry Vyukov wrote: > On Thu, 2 Mar 2023 at 10:04, Thorsten Leemhuis <linux@leemhuis.info> wrote: >> On 02.03.23 09:27, Dmitry Vyukov wrote: >>> On Thu, 2 Mar 2023 at 06:40, Jakub Kicinski <kuba@kernel.org> wrote: >>>> On Thu, 2 Mar 2023 06:17:22 +0100 Thorsten Leemhuis wrote: >>>>> On 02.03.23 05:46, Jakub Kicinski wrote: >>>>>> On Fri, 20 Jan 2023 13:35:19 +0100 Thorsten Leemhuis wrote: >>>>>>> Encourage patch authors to link to reports by issuing a warning, if >>>>>>> a Reported-by: is not accompanied by a link to the report. Those links >>>>>>> are often extremely useful for any code archaeologist that wants to know >>>>>>> more about the backstory of a change than the commit message provides. >>>>>>> That includes maintainers higher up in the patch-flow hierarchy, which >>>>>>> is why Linus asks developers to add such links [1, 2, 3]. To quote [1]: >>>>>> >>>>>> Is it okay if we exclude syzbot reports from this rule? >>>>>> If full syzbot report ID is provided - it's as good as a link. >>>>> >>>>> Hmmm. Not sure. Every special case makes things harder for humans and >>>>> software that looks at a commits downstream. Clicking on a link also >>>>> makes things easy for code archaeologists that might look into the issue >>>>> months or years later (which might not even know how to find the report >>>>> and potential discussions on lore from the syzbot report ID). >>>> >>>> No other system comes close to syzbot in terms of reporting meaningful >>>> bugs, IMHO special casing it doesn't risk creep. >>>> >>>> Interestingly other bots attach links which are 100% pointless noise: >>>> >>>> Reported-by: Abaci Robot <abaci@linux.alibaba.com> >>>> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4174 >>>> >>>> Oh, eh. Let's see how noisy this check is once the merge window is over. >>>> >>>>> Hence, wouldn't it be better to ask the syzbot folks to change their >>>>> reporting slightly and suggest something like this instead in their >>>>> reports (the last line is the new one): >>>>> >>>>> ``` >>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit: >>>>> Reported-by: syzbot+bba886ab504fcafecafe@syzkaller.appspotmail.com >>>>> Link: https://lore.kernel.org/r/cafecaca0cafecaca0cafecaca0@google.com/ >>>>> ``` >>>>> >>>>> This might not be to hard if they known the message-id in advance. Maybe >>>>> they could even use the syzbot report ID as msg-id to make things even >>>>> easier. And for developers not much would change afaics, they just need >>>>> to copy and paste two lines instead of one. >>>> >>>> Dmitry, WDYT? >>> >>> Adding a Link to syzbot reports should be relatively trivial. >> >> Sounds good. >> >>> Ted proposed to use Link _instead_ of Reported-by: >>> https://github.com/google/syzkaller/issues/3596 >>>> in fact, it might be nice if we could encourage upstream developers >>>> put in the commit trailer: >>>> Link: https://syzkaller.appspot.com/bug?id=5266d464285a03cee9dbfda7d2452a72c3c2ae7c >>>> in addition to, or better yet, instead of: >>>> Reported-by: syzbot+15cd994e273307bf5cfa@syzkaller.appspotmail.com >>> >>> We could also use a link in the Reported-by tag, e.g.: >>> >>> Reported-by: https://syzkaller.appspot.com/b/5266d464285a03cee9db >>> >>> Some folks parse Reported-by to collect stats. >>> >>> What is better? >> >> Here are my thoughts: >> >> * we should definitely have a "Link:" to the report in lore, as that's >> the long-term archive under our own control and also where discussions >> happen after the report was posted; but I'm biased here, as such a tag >> would make tracking with regzbot a no-brainer ;) >> >> * "Reported-by:" IMHO should stay for the hat tip and stats aspects; I >> don't care if it includes the syzbot report ID or not (omitting it might >> be good for the stats aspects and is more friendly to the eyes, but >> those are just details) >> >> * a Link: to the syzkaller web ui might be nice, too -- and likely is >> the easiest thing to look out for on the syzbot server side >> >> IOW something like this maybe: >> >> Reported-by: syzbot+cafecafecaca0cafecafe@syzkaller.appspotmail.com >> Link: https://lore.kernel.org/r/cafecafecaca0cafecafe@google.com/ >> Link: https://syzkaller.appspot.com/b/cafecafecaca0cafecafe >> >> Something like the following would look more normal, but of course is >> only possible if syzbot starts out to look for such Link: tags (not sure >> if the msgid is valid here, but you get the idea): >> >> Reported-by: syzbot@syzkaller.appspotmail.com >> Link: >> https://lore.kernel.org/r/syzbot+cafecafecaca0cafecafe-syzkaller-appspotmail-com@google.com/ > > Oh, you mean lore link. > > We can parse out our hash from any tag, but the problem is that the > current email api we use, does not allow to specify Message-ID before > sending, so we don't know it when generating the text. > We don't even know it after sending, the API is super simple: > https://pkg.go.dev/google.golang.org/appengine/mail > So we don't know what the lore link will be... That's... unfortunate, as from my understanding of things that would be the most important "Link:" to have in any patches that fix issues report by syzbot. But well, that's how it is for now. In that case I'd vote for this: Reported-by: syzbot@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/b/cafecafecaca0cafecafe Regzbot can handle this, as long as somebody tells it about that URL. IOW: it creates a little extra work for some human. But that is not much of a problem, especially as of now, as I only track syzbot reports that for one reason or another make me go "I should better track this". Ciao, Thorsten
On Thu, 2 Mar 2023 10:48:22 +0100 Thorsten Leemhuis <linux@leemhuis.info> wrote: > > We can parse out our hash from any tag, but the problem is that the > > current email api we use, does not allow to specify Message-ID before > > sending, so we don't know it when generating the text. > > We don't even know it after sending, the API is super simple: > > https://pkg.go.dev/google.golang.org/appengine/mail > > So we don't know what the lore link will be... > > That's... unfortunate, as from my understanding of things that would be > the most important "Link:" to have in any patches that fix issues report > by syzbot. But well, that's how it is for now. In that case I'd vote for > this: > > Reported-by: syzbot@syzkaller.appspotmail.com > Link: https://syzkaller.appspot.com/b/cafecafecaca0cafecafe As you previously mentioned, patch preparers should also include the lore link so any followup discussion is easily located.
On Fri, 3 Mar 2023 at 03:10, Andrew Morton <akpm@linux-foundation.org> wrote: > > > We can parse out our hash from any tag, but the problem is that the > > > current email api we use, does not allow to specify Message-ID before > > > sending, so we don't know it when generating the text. > > > We don't even know it after sending, the API is super simple: > > > https://pkg.go.dev/google.golang.org/appengine/mail > > > So we don't know what the lore link will be... > > > > That's... unfortunate, as from my understanding of things that would be > > the most important "Link:" to have in any patches that fix issues report > > by syzbot. But well, that's how it is for now. In that case I'd vote for > > this: > > > > Reported-by: syzbot@syzkaller.appspotmail.com > > Link: https://syzkaller.appspot.com/b/cafecafecaca0cafecafe > > As you previously mentioned, patch preparers should also include > the lore link so any followup discussion is easily located. If the link we need to include is to lore, then we don't need to change the current syzbot Reported-by, right? Instead of asking 3 tags, we can ask only for: Reported-by: syzbot+df61b36319e045c00a08@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/cafecafecaca0cafecafe@google.com/ But as I mentioned we can't provide the lore link at the moment, we can only add a text to ask to include it. This also means that checkpatch does not need special casing for syzbot.
On 06.03.23 09:53, Dmitry Vyukov wrote: > On Fri, 3 Mar 2023 at 03:10, Andrew Morton <akpm@linux-foundation.org> wrote: >>>> We can parse out our hash from any tag, but the problem is that the >>>> current email api we use, does not allow to specify Message-ID before >>>> sending, so we don't know it when generating the text. >>>> We don't even know it after sending, the API is super simple: >>>> https://pkg.go.dev/google.golang.org/appengine/mail >>>> So we don't know what the lore link will be... >>> >>> That's... unfortunate, as from my understanding of things that would be >>> the most important "Link:" to have in any patches that fix issues report >>> by syzbot. But well, that's how it is for now. In that case I'd vote for >>> this: >>> >>> Reported-by: syzbot@syzkaller.appspotmail.com >>> Link: https://syzkaller.appspot.com/b/cafecafecaca0cafecafe >> >> As you previously mentioned, patch preparers should also include >> the lore link so any followup discussion is easily located. > > If the link we need to include is to lore, then we don't need to > change the current syzbot Reported-by, right? Instead of asking 3 > tags, we can ask only for: > > Reported-by: syzbot+df61b36319e045c00a08@syzkaller.appspotmail.com > Link: https://lore.kernel.org/r/cafecafecaca0cafecafe@google.com/ Yeah, that's not perfect (see below), but at least better. As mentioned earlier: if the Reported-by: includes the sysbot-id (e.g. the df61b36319e045c00a08) is up to you. > But as I mentioned we can't provide the lore link at the moment, we > can only add a text to ask to include it. Yeah, that would be good. Normally it's the oblation of the developer anyway to add Link: tags to any report (which most of the time means: in lore) when fixing things. Obviously the chance that they actually do it is a lot bigger when syzbot would suggest it. > This also means that checkpatch does not need special casing for syzbot. Yup Ciao, Thorsten
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index d739ce0909b1..b74d6002f773 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -3155,8 +3155,20 @@ sub process { "Co-developed-by and Signed-off-by: name/email do not match \n" . "$here\n" . $rawline . "\n" .$rawlines[$linenr]); } } + +# check if Reported-by: is followed by a Link: + if ($sign_off =~ /^reported(?:|-and-tested)-by:$/i) { + if (!defined $lines[$linenr]) { + WARN("BAD_REPORTED_BY_LINK", + "Reported-by: should be immediately followed by Link: to the report\n" . $herecurr . $rawlines[$linenr] . "\n"); + } elsif ($rawlines[$linenr] !~ m{^link:\s*https?://}i) { + WARN("BAD_REPORTED_BY_LINK", + "Reported-by: should be immediately followed by Link: with a URL to the report\n" . $herecurr . $rawlines[$linenr] . "\n"); + } + } } + # Check Fixes: styles is correct if (!$in_header_lines && $line =~ /^\s*fixes:?\s*(?:commit\s*)?[0-9a-f]{5,}\b/i) {