* Re: Stop false review statements
From: Krzysztof Kozlowski @ 2026-05-16 21:33 UTC (permalink / raw)
To: debarbos, Arnaldo Carvalho de Melo
Cc: Roman Gushchin, Greg KH, Konstantin Ryabitsev, Guenter Roeck,
sashiko-bot, sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree, kfree
In-Reply-To: <agjb7-q-p2SemgJa@debarbos-thinkpadt14gen5.rmtusma.csb>
On 16/05/2026 23:29, Derek Barbosa wrote:
> On Sat, May 16, 2026 at 03:28:47PM -0300, Arnaldo Carvalho de Melo wrote:
>>
>> Couldn't this be something like:
>>
>> AI-analysed-by: bot-X
>
> +1
But why? What is the benefit of storing in Git log information that some
tool did work?
We do not store checkpatch result (another pattern matching tool),
Coverity, Smatch, LKP or syzkallers.
Instead just blank +1 please provide arguments why this is useful for us.
I find it opposite: clogging commits with useless information, because
some arbitrary and completely closed-source tool did analysis means
nothing to me one year later when I look at the commit in the Git history.
Best regards,
Krzysztof
^ permalink raw reply
* Re: Stop false review statements
From: Derek Barbosa @ 2026-05-16 21:29 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Roman Gushchin, Greg KH, Konstantin Ryabitsev, Guenter Roeck,
Krzysztof Kozlowski, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List, devicetree,
kfree
In-Reply-To: <agi3X76XwcBJ-KmH@x1>
On Sat, May 16, 2026 at 03:28:47PM -0300, Arnaldo Carvalho de Melo wrote:
>
> Couldn't this be something like:
>
> AI-analysed-by: bot-X
+1
78d979db6cef5 ("docs: add AI Coding Assistants documentation") introduced the
coding-assistants document some time ago [0]. In that time span, we've
seen a quick rise in popularity for tools that leverage reviews through the use
of LLMs.
And while the document does call out general AI contributions with:
> Contributions should include an Assisted-by tag in the following format:
expanding it to include something like "AI-analyzed-by" would be nice.
> So, yeah, Reviewed-by is definetly for definetly persons, but having
> some tag that states that it went thru automated reviewing^Wanalysis by
> a definetly bot/thing/whatever that some people think is useful seems
> useful.
Agreed. I think there is a distinction (although a pedantic one) between a
Generated-by/Assisted-by and something like "AI-analyzed" :-)
[0] https://lore.kernel.org/lkml/20251223122110.2496946-1-sashal@kernel.org/
--
Derek <debarbos@redhat.com>
^ permalink raw reply
* Re: Stop false review statements
From: Mauro Carvalho Chehab @ 2026-05-16 21:10 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Krzysztof Kozlowski, Guenter Roeck, sashiko-bot, sashiko-reviews,
sashiko, Linux Kernel Workflows, Linux Kernel Mailing List,
devicetree@vger.kernel.org, kfree
In-Reply-To: <20260516132407.GA163589@killaraus.ideasonboard.com>
On Sat, 16 May 2026 16:24:07 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> On Sat, May 16, 2026 at 02:29:15PM +0200, Krzysztof Kozlowski wrote:
> > On 16/05/2026 14:23, Guenter Roeck wrote:
> > > On 5/16/26 05:16, Krzysztof Kozlowski wrote:
> > >> On 16/05/2026 14:11, Guenter Roeck wrote:
> > >>> On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
> > >>>> What the hell is that:
> > >>>>
> > >>>> https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
> > >>>>
> > >>>> As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
> > >>>> not a damn human do be able to make such statement. You are a bot, a tool.
> > >>>>
> > >>>
> > >>> Where exactly do the rules say that ? I seem to miss that.
> > >>>
> > >>> There is a policy document about _contributions_ made by AI, but I don't
> > >>> see the one that says that AI agents must not provide Reviewed-by: tags.
> > >>
> > >> Quotes from the existing policy:
> > >>
> > >> 1. "By offering my Reviewed-by: tag, I state that:"
> > >>
> > >> Tool cannot use first person "I". Tool cannot "state that".
> > >>
> > >> 2. "A Reviewed-by tag is *a statement of opinion* that the patch is an
> > >> appropriate modification of the kernel without any remaining serious"
> > >>
> > >> Tool cannot make a statement of opinion.
> > >>
> > >> 3. "Any interested reviewer (who has done the work) can offer a
> > >> Reviewed-by".
> > >>
> > >> Tool is not a reviewer as a person, thus above does not grant the tool
> > >> permission to offer a tag.
> > >
> > > I'd like to see that explicitly spelled out. Until then it is your opinion.
> >
> > It is not an opinion. It is written. I gave you quotes.
> >
> > Do you want to spell the rules of English language? That tool is not a
> > person?
> >
> > Shall I send the patch like:
> >
> > Any interested reviewer (who has done the work) can offer a
> > Reviewed-by.
> > +In English "reviewer" is a person [1].
> > + [1] https://en.wiktionary.org/wiki/reviewer
Agreed. Reviewed-by doesn't apply.
> >
> > Seriously, you expect to document the English language?
> >
> > >>>> Stop faking tags.
> > >>>>
> > >>>> And really, considering how many false positives Sashiko produces, how
> > >>>> poor review comments it gives, how many misleading comments, it's
> > >>>> unacceptable to me to consider that a review.
> > >>>>
> > >>>> Amount of useless noise Sashiko produces already changed my mind how
> > >>>> useful that tool is.
>
> Note this isn't en entirely new situation. As a maintainer, you know how
> much you trust each reviewer. You will consider some R-b tags as a sign
> you don't even have to look at a patch, and will completely ignore some
> others. There's a whole continuum in the middle. In some ways, reviews
> by an LLM are similar. You will trust them or not trust them.
>
> Except they're also very different.
This is not different than Coverity, Smatch, syzbot or any other robots (*).
(*) except for the ones that report actual build failures after trying
to compile the Kernel.
So far, I got just one report from sashiko-bot on a patch series
I wrote for linux-doc. It did get some issues, but it also had false
positives and it was too verbose for my taste, trying to explain
me why I wrote patches or why I did some changes, and writing 9
patch replies to a 13-patch series.
Even as a developer, I would expect a much cleaner output - and
with my maintainer's hat, just a single e-mail briefly giving
a summary of issues detected at the patch series as a hole
(e.g. just one short e-mail).
> As such, I think that a R-b from an LLM is misleading and
> doesn't provide good value. At best it's free advertising for company
> making closed-source tools, which I don't think we should encourage.
I disagree. The earliest an issue is reported/fixed, the better.
As a maintainer, I do want that patch developers take reports from
any bots into account, no matter what technology they use or if
the bot is sponsored by someone or not. Sure, open-source tools
are preferred, but we should not close our eyes to issues,
specially if they can end adding vulnerabilities at the Kernel if
the patches end being applied.
With that in mind, even if LLMs are giving just 20-30% accuracy
of a reviewer, but it has high accuracy picking security issues
that would otherwise be exploited by some LLM tool, I'd say it is
valuable enough.
That said, for LLM tools, I'd say that the report to maintainers/ML
need to be very short:
- What problems a patch series may have in terms of security
(OOM? privilege escalation? ...);
- What major issues a patch series may have;
- Other medium issues(*).
(*) Issues that are already reported by bots like LKP shall not
be reported from LLMs to maintainers, as we want to minimize
duplicated information sent to maintainers as much as possible,
and LLMs don't replace code compilers nor tools like checkpatch,
which are more specialized.
Thanks,
Mauro
^ permalink raw reply
* Re: Stop false review statements
From: Theodore Tso @ 2026-05-16 20:41 UTC (permalink / raw)
To: Roman Gushchin
Cc: Krzysztof Kozlowski, Greg KH, Konstantin Ryabitsev, Guenter Roeck,
sashiko-bot, sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree, kfree
In-Reply-To: <FA45D2AD-1135-4480-8423-63C0D37FE78D@linux.dev>
On Sat, May 16, 2026 at 12:15:12PM -0700, Roman Gushchin wrote:
> > The trouble is that subsystem is mailing list, thus I still got all of
> > them via b4, which is used to get the discussion.
> >
> > Send them only to the maintainer, for example. Or maintainer + authors.
> >
> > Basically the same as LKP is doing.
>
> There are subsystems which want email reviews to be sent to the subsystem
> mailing list. In fact, all currently configured email policies came from maintainers,
> I don’t push anything based on my own preferences.
In the case of ext4, we have a weekly video conference of the core
developers, and last week I asked the ext4 core developers whether we
should start cc'ing the linux-ext4 list. When I first asked Roman to
send the reviews to the me as the reviewer and the patch author, I
didn't want to cc the list in the case people would find annoying.
The discussion in our video chat was that the quality of the reviews
was quite good, and the only feedback from the ext4 developers was (a)
pre-existing problems that were unrelated the patch series, (b)
sometimes the problems that was pointed out are ones that we don't
care about (for example, there was a recent comment about readahead
detection being racy, and that was not ext4-specific, and readahead is
a hint and if two processes are reading the file at the same
time.... oh cares how the system handles the hueristic of something
which is a hint anyway), and (c) while Shashiko is good at pointing
out problems, its suggestted solutions aren't as good.
But that's OK, on the whole, the Sashiko is finding problems that
humans very familiar with code base had missed. And so it's certainly
better than most human reviewers.
Based on that, the consensus of the ext4 core developers that it would
be better to make sure that the linux-ext4 list should be cc'ed. So
that's a decision that didn't come from me as the ext4 maintainer, but
after consulting with core ext4 developers and reviewers.
> I agree, it’s sometimes gets tricky when a patchset is sent to
> multiple mailing lists, which policy to apply.
What I would suggest is that if we have a patch which is cc'ed to say,
linux-xfs, linux-ext4, and linux-fsdevel, as well as a dozen
developers suggested by get_maintainer.pl, and only the ext4 list has
requested the reviews, then only send it to the ext4 maintainer, the
ext4 mailing list, and the patch author. The Sashiko review doesn't
need to be cc'ed to the other lists, or the dozen or so other
maintainers.
Cheers,
- Ted
^ permalink raw reply
* Re: Stop false review statements
From: Roman Gushchin @ 2026-05-16 19:31 UTC (permalink / raw)
To: Guenter Roeck
Cc: Krzysztof Kozlowski, Greg KH, Konstantin Ryabitsev, sashiko-bot,
sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree, kfree
In-Reply-To: <35412149-282f-4272-ba47-136caeeb5c1b@roeck-us.net>
> On May 16, 2026, at 12:25 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 5/16/26 12:13, Guenter Roeck wrote:
>> On 5/16/26 12:00, Krzysztof Kozlowski wrote:
>> ...
>>>> It’s opt-in on per-subsystem basis, as well as all other email-related features.
>>>> I do rely on corresponding maintainers to decide if they want it or not.
>>>
>>> The trouble is that subsystem is mailing list, thus I still got all of
>>> them via b4, which is used to get the discussion.
>>>
>>> Send them only to the maintainer, for example. Or maintainer + authors.
>>>
>> For hwmon and watchdog I most definitely want the response sent to the
>> mailing list and to the patch author. That was the original configuration
>> for hwmon. Roman took it out because people who were copied on the
>> original patch complained that they did _not_ get Sashiko's reply.
>
> Actually, turns out he didn't, he just moved it.
>
> However, it turns out that Rob added krzk+dt@kernel.org as explicit
> Cc: target for the devicetree subsystem. I would suggest to drop that.
I already did.
I haven’t changed the hwmon configuration.
Thanks
^ permalink raw reply
* Re: Stop false review statements
From: Guenter Roeck @ 2026-05-16 19:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, Roman Gushchin
Cc: Greg KH, Konstantin Ryabitsev, sashiko-bot, sashiko-reviews,
sashiko, Linux Kernel Workflows, Linux Kernel Mailing List,
devicetree, kfree
In-Reply-To: <dd37929b-ff90-4567-930a-26db01d85950@roeck-us.net>
On 5/16/26 12:13, Guenter Roeck wrote:
> On 5/16/26 12:00, Krzysztof Kozlowski wrote:
> ...
>
>>> It’s opt-in on per-subsystem basis, as well as all other email-related features.
>>> I do rely on corresponding maintainers to decide if they want it or not.
>>
>> The trouble is that subsystem is mailing list, thus I still got all of
>> them via b4, which is used to get the discussion.
>>
>> Send them only to the maintainer, for example. Or maintainer + authors.
>>
>
> For hwmon and watchdog I most definitely want the response sent to the
> mailing list and to the patch author. That was the original configuration
> for hwmon. Roman took it out because people who were copied on the
> original patch complained that they did _not_ get Sashiko's reply.
Actually, turns out he didn't, he just moved it.
However, it turns out that Rob added krzk+dt@kernel.org as explicit
Cc: target for the devicetree subsystem. I would suggest to drop that.
Thanks,
Guenter
^ permalink raw reply
* Re: Stop false review statements
From: Roman Gushchin @ 2026-05-16 19:15 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Greg KH, Konstantin Ryabitsev, Guenter Roeck, sashiko-bot,
sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree, kfree
In-Reply-To: <b5989c0f-90da-42cc-a623-3b60df077848@kernel.org>
> On May 16, 2026, at 12:00 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 16/05/2026 20:56, Roman Gushchin wrote:
>>
>>
>>>> On May 16, 2026, at 11:29 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>
>>> On 16/05/2026 17:49, Roman Gushchin wrote:
>>>>>
>>>>>> I’m not attached to any specific form of it, I thought Reviewed-by is the most obvious form.
>>>>>> And we use Reported-by: tags with various tooling for years.
>>>>>
>>>>> Reported-by: shows the existance of a problem that some tool found, a
>>>>> subtle difference here.
>>>>>
>>>>>> What do you think is the best form?
>>>>>>
>>>>>> I’ll pause sending reviewed-by tags until we have a discussion and agreement here.
>>>>>
>>>>> Just say it in some other text form, that our tools will not pick up.
>>>>> Like:
>>>>> Tool XXXX reports that all is good:
>>>>> https://....
>>>>>
>>>>> or something like that?
>>>>
>>>> Sure, works for me.
>>> Roman,
>>> Before implementing such changes, send a RFC or just ask a few folks for
>>> opinions. We do use the tool, among other tools, so we will gladly
>>> provide a feedback.
>>>
>>> Sashiko should in general not send such emails when not asked for. Why?
>>> Because we have also other bots, like LKP, KernelCI, and imagine how
>>> maintainer's mailbox will look like.
>>>
>>> LKP allows opt-in for your own repo, which for example I am using, so I
>>> get confirmation of the success. But people are not receiving them. I
>>> cannot imagine all the people getting these LKP-successfully-built
>>> emails on every email.
>>
>> It’s opt-in on per-subsystem basis, as well as all other email-related features.
>> I do rely on corresponding maintainers to decide if they want it or not.
>
> The trouble is that subsystem is mailing list, thus I still got all of
> them via b4, which is used to get the discussion.
>
> Send them only to the maintainer, for example. Or maintainer + authors.
>
> Basically the same as LKP is doing.
There are subsystems which want email reviews to be sent to the subsystem
mailing list. In fact, all currently configured email policies came from maintainers,
I don’t push anything based on my own preferences.
Sashiko can be configured the way you describe it or in any other way, it’s up to corresponding
maintainers.
I agree, it’s sometimes gets tricky when a patchset is sent to multiple mailing lists,
which policy to apply. I have some improvements in my plans, but it’s not always possible
to say how it should be handled. It’s not fundamentally new: landing changes touching
multiple subsystems is always harder exactly because maintainers might have different
and sometimes conflicting views.
>
>> If you’re saying that it should not send any non-personal emails in general, I disagree here,
>> but happy to have a discussion, assuming it’s polite and constructive.
>
> I meant it should not be send to people who did not request that. Opt-in
> should be explicit and no mailing lists must be Cced (because then it is
> sending to everyone).
>>
>> The reason why I disagree is simple: there are maintainers/subsystems who like Sashiko’s reviews
>> and before introducing the email interface they had to manually send links to Sashiko’s reviews
>> as replies to proposed patches. I’ve been explicitly asked to add an ability to send out
>> emails with reviews.
>
> Sure, I agree with the need for use-case.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: Stop false review statements
From: Guenter Roeck @ 2026-05-16 19:13 UTC (permalink / raw)
To: Krzysztof Kozlowski, Roman Gushchin
Cc: Greg KH, Konstantin Ryabitsev, sashiko-bot, sashiko-reviews,
sashiko, Linux Kernel Workflows, Linux Kernel Mailing List,
devicetree, kfree
In-Reply-To: <b5989c0f-90da-42cc-a623-3b60df077848@kernel.org>
On 5/16/26 12:00, Krzysztof Kozlowski wrote:
...
>> It’s opt-in on per-subsystem basis, as well as all other email-related features.
>> I do rely on corresponding maintainers to decide if they want it or not.
>
> The trouble is that subsystem is mailing list, thus I still got all of
> them via b4, which is used to get the discussion.
>
> Send them only to the maintainer, for example. Or maintainer + authors.
>
For hwmon and watchdog I most definitely want the response sent to the
mailing list and to the patch author. That was the original configuration
for hwmon. Roman took it out because people who were copied on the
original patch complained that they did _not_ get Sashiko's reply.
That is a perfect lose-lose situation.
Guenter
^ permalink raw reply
* Re: Stop false review statements
From: Krzysztof Kozlowski @ 2026-05-16 19:00 UTC (permalink / raw)
To: Roman Gushchin
Cc: Greg KH, Konstantin Ryabitsev, Guenter Roeck, sashiko-bot,
sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree, kfree
In-Reply-To: <70C5331E-06F1-48D5-A6BA-0CD130B69A45@linux.dev>
On 16/05/2026 20:56, Roman Gushchin wrote:
>
>
>> On May 16, 2026, at 11:29 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 16/05/2026 17:49, Roman Gushchin wrote:
>>>>
>>>>> I’m not attached to any specific form of it, I thought Reviewed-by is the most obvious form.
>>>>> And we use Reported-by: tags with various tooling for years.
>>>>
>>>> Reported-by: shows the existance of a problem that some tool found, a
>>>> subtle difference here.
>>>>
>>>>> What do you think is the best form?
>>>>>
>>>>> I’ll pause sending reviewed-by tags until we have a discussion and agreement here.
>>>>
>>>> Just say it in some other text form, that our tools will not pick up.
>>>> Like:
>>>> Tool XXXX reports that all is good:
>>>> https://....
>>>>
>>>> or something like that?
>>>
>>> Sure, works for me.
>> Roman,
>> Before implementing such changes, send a RFC or just ask a few folks for
>> opinions. We do use the tool, among other tools, so we will gladly
>> provide a feedback.
>>
>> Sashiko should in general not send such emails when not asked for. Why?
>> Because we have also other bots, like LKP, KernelCI, and imagine how
>> maintainer's mailbox will look like.
>>
>> LKP allows opt-in for your own repo, which for example I am using, so I
>> get confirmation of the success. But people are not receiving them. I
>> cannot imagine all the people getting these LKP-successfully-built
>> emails on every email.
>
> It’s opt-in on per-subsystem basis, as well as all other email-related features.
> I do rely on corresponding maintainers to decide if they want it or not.
The trouble is that subsystem is mailing list, thus I still got all of
them via b4, which is used to get the discussion.
Send them only to the maintainer, for example. Or maintainer + authors.
Basically the same as LKP is doing.
> If you’re saying that it should not send any non-personal emails in general, I disagree here,
> but happy to have a discussion, assuming it’s polite and constructive.
I meant it should not be send to people who did not request that. Opt-in
should be explicit and no mailing lists must be Cced (because then it is
sending to everyone).
>
> The reason why I disagree is simple: there are maintainers/subsystems who like Sashiko’s reviews
> and before introducing the email interface they had to manually send links to Sashiko’s reviews
> as replies to proposed patches. I’ve been explicitly asked to add an ability to send out
> emails with reviews.
Sure, I agree with the need for use-case.
Best regards,
Krzysztof
^ permalink raw reply
* Re: Stop false review statements
From: Roman Gushchin @ 2026-05-16 18:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Greg KH, Konstantin Ryabitsev, Guenter Roeck, sashiko-bot,
sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree, kfree
In-Reply-To: <efc4d394-b328-4ccf-8c05-b6470ee4b88d@kernel.org>
> On May 16, 2026, at 11:29 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 16/05/2026 17:49, Roman Gushchin wrote:
>>>
>>>> I’m not attached to any specific form of it, I thought Reviewed-by is the most obvious form.
>>>> And we use Reported-by: tags with various tooling for years.
>>>
>>> Reported-by: shows the existance of a problem that some tool found, a
>>> subtle difference here.
>>>
>>>> What do you think is the best form?
>>>>
>>>> I’ll pause sending reviewed-by tags until we have a discussion and agreement here.
>>>
>>> Just say it in some other text form, that our tools will not pick up.
>>> Like:
>>> Tool XXXX reports that all is good:
>>> https://....
>>>
>>> or something like that?
>>
>> Sure, works for me.
> Roman,
> Before implementing such changes, send a RFC or just ask a few folks for
> opinions. We do use the tool, among other tools, so we will gladly
> provide a feedback.
>
> Sashiko should in general not send such emails when not asked for. Why?
> Because we have also other bots, like LKP, KernelCI, and imagine how
> maintainer's mailbox will look like.
>
> LKP allows opt-in for your own repo, which for example I am using, so I
> get confirmation of the success. But people are not receiving them. I
> cannot imagine all the people getting these LKP-successfully-built
> emails on every email.
It’s opt-in on per-subsystem basis, as well as all other email-related features.
I do rely on corresponding maintainers to decide if they want it or not.
Even in the case which you was so unhappy about, I asked Guenter prior
to enabling it for hwmon.
If you’re saying that it should not send any non-personal emails in general, I disagree here,
but happy to have a discussion, assuming it’s polite and constructive.
The reason why I disagree is simple: there are maintainers/subsystems who like Sashiko’s reviews
and before introducing the email interface they had to manually send links to Sashiko’s reviews
as replies to proposed patches. I’ve been explicitly asked to add an ability to send out
emails with reviews.
Thanks
^ permalink raw reply
* Re: Stop false review statements
From: Krzysztof Kozlowski @ 2026-05-16 18:28 UTC (permalink / raw)
To: Roman Gushchin, Greg KH
Cc: Konstantin Ryabitsev, Guenter Roeck, sashiko-bot, sashiko-reviews,
sashiko, Linux Kernel Workflows, Linux Kernel Mailing List,
devicetree, kfree
In-Reply-To: <0902F8E6-C495-40A1-975D-92D3B72D44AE@linux.dev>
On 16/05/2026 17:49, Roman Gushchin wrote:
>>
>>> I’m not attached to any specific form of it, I thought Reviewed-by is the most obvious form.
>>> And we use Reported-by: tags with various tooling for years.
>>
>> Reported-by: shows the existance of a problem that some tool found, a
>> subtle difference here.
>>
>>> What do you think is the best form?
>>>
>>> I’ll pause sending reviewed-by tags until we have a discussion and agreement here.
>>
>> Just say it in some other text form, that our tools will not pick up.
>> Like:
>> Tool XXXX reports that all is good:
>> https://....
>>
>> or something like that?
>
> Sure, works for me.
Roman,
Before implementing such changes, send a RFC or just ask a few folks for
opinions. We do use the tool, among other tools, so we will gladly
provide a feedback.
Sashiko should in general not send such emails when not asked for. Why?
Because we have also other bots, like LKP, KernelCI, and imagine how
maintainer's mailbox will look like.
LKP allows opt-in for your own repo, which for example I am using, so I
get confirmation of the success. But people are not receiving them. I
cannot imagine all the people getting these LKP-successfully-built
emails on every email.
Best regards,
Krzysztof
^ permalink raw reply
* Re: Stop false review statements
From: Arnaldo Carvalho de Melo @ 2026-05-16 18:28 UTC (permalink / raw)
To: Roman Gushchin
Cc: Greg KH, Konstantin Ryabitsev, Guenter Roeck, Krzysztof Kozlowski,
sashiko-bot, sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree, kfree
In-Reply-To: <0902F8E6-C495-40A1-975D-92D3B72D44AE@linux.dev>
On Sat, May 16, 2026 at 08:49:39AM -0700, Roman Gushchin wrote:
> > On May 16, 2026, at 8:45 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Sat, May 16, 2026 at 08:41:43AM -0700, Roman Gushchin wrote:
> >>>> On May 16, 2026, at 8:20 AM, Konstantin Ryabitsev <mricon@kernel.org> wrote:
> >>> On Sat, May 16, 2026 at 05:11:28AM -0700, Guenter Roeck wrote:
> >>>>> On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
> >>>>> What the hell is that:
>
> >>>>> https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
> >>>>> As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
> >>>>> not a damn human do be able to make such statement. You are a bot, a tool.
> >>>> Where exactly do the rules say that ? I seem to miss that.
> >>>> There is a policy document about _contributions_ made by AI, but I don't
> >>>> see the one that says that AI agents must not provide Reviewed-by: tags.
> >>> From my perspective, AI agents must NOT use the Reviewed-by tag for the
> >>> following reasons:
> >>> - We consider this a "person-trailer" and it implies agency
> >>> - Adding yourself to a commit via a trailer is a *binding responsibility* for
> >>> the change. A lot of tooling will cc the Reviewed-by addresses on follow-up
> >>> messages regarding code in this commit. If the address is bogus or doesn't
> >>> go to a developer, this is both wasteful and potentially frustrating.
> >> Hi Konstantin!
> >> The goal here is to inform maintainers that sashiko has successfully reviewed the patch
> >> and there were no findings, otherwise maintainers have to go to the web site and check the status.
> > That's fine.
> >> I’m not attached to any specific form of it, I thought Reviewed-by is the most obvious form.
> >> And we use Reported-by: tags with various tooling for years.
> > Reported-by: shows the existance of a problem that some tool found, a
> > subtle difference here.
> >> What do you think is the best form?
> >> I’ll pause sending reviewed-by tags until we have a discussion and agreement here.
> > Just say it in some other text form, that our tools will not pick up.
> > Like:
> > Tool XXXX reports that all is good:
> > https://....
> > or something like that?
> Sure, works for me.
Couldn't this be something like:
AI-analysed-by: bot-X
Sometimes we expect them to run and produce results, that we should
check, and in my experience act upon and sometimes ignore, as usual with
any type of comments, when I don't get those results I usually go and
look at the web interface, be it the public one or the private one I use
(while contributing to one of them, sashiko for full disclosure), to see
if it is just that it is taking longer to process that specific patch or
if it really finished.
If I go in the morning to look at my inbox and see everything there it
reduces some steps for me.
So, yeah, Reviewed-by is definetly for definetly persons, but having
some tag that states that it went thru automated reviewing^Wanalysis by
a definetly bot/thing/whatever that some people think is useful seems
useful.
And of course I think this should be all opt-in by each and every
maintainer, this definetly is not something to be uniformly agreed on,
so if some mechanism is put in place for, say, sashiko, to reply that it
didn't find any problem with a particular patch for the subsystem I'm
involved with, then I'd like for that info to be provided as a reply to
the message.
Cheers,
- Arnaldo
^ permalink raw reply
* Re: [PATCH v2 1/3] Doc: deprecated.rst: add strlcat()
From: David Laight @ 2026-05-16 16:35 UTC (permalink / raw)
To: Heiko Carstens
Cc: Kees Cook, Manuel Ebner, Andy Shevchenko, Jonathan Corbet,
Shuah Khan, Andy Whitcroft, Joe Perches, Dwaipayan Ray,
Lukas Bulwahn, Geert Uytterhoeven, Randy Dunlap, Jani Nikula,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION,
open list
In-Reply-To: <20260516152819.14597A76-hca@linux.ibm.com>
On Sat, 16 May 2026 17:28:19 +0200
Heiko Carstens <hca@linux.ibm.com> wrote:
> On Thu, May 14, 2026 at 09:31:46AM -0700, Kees Cook wrote:
> > On Thu, May 14, 2026 at 06:26:53PM +0200, Manuel Ebner wrote:
> > > add strlcat and alternatives
> > >
> > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > > ---
> > > Documentation/process/deprecated.rst | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> > > index fed56864d036..06e802f4bbfd 100644
> > > --- a/Documentation/process/deprecated.rst
> > > +++ b/Documentation/process/deprecated.rst
> > > @@ -153,6 +153,13 @@ used, and the destinations should be marked with the `__nonstring
> > > attribute to avoid future compiler warnings. For cases still needing
> > > NUL-padding, strtomem_pad() can be used.
> > >
> > > +strlcat()
> > > +---------
> > > +strlcat() must re-scan the destination string from the beginning on each
> > > +call (O(n^2) behavior). Alternatives are seq_buf_puts() and seq_buf_printf().
> > > +snprintf(), scnprintf() and sysfs_emit() are possible aswell, but the adoption
> > > +of the arguments needs to be taken care off.
> > > +
> >
> > How about just:
> >
> > strlcat() must re-scan the destination string from the beginning on each
> > call (O(n^2) behavior). Use the seq_buf API or similar instead.
>
> seq_buf API for appending something to e.g. boot_command_line seems to be odd,
> since boot_command_line is usually "just there" (depending on architecture and
> boot loader).
Indeed, but ISTR that code uses strcat() a lot of the time.
The lengths are all known, so memcpy() can be used.
I don't really see why strlcat() should be deprecated.
Clearly there are many cases where there are better ways to do things.
The only problem with strlcat() is that it returns the 'required length'.
So there are some broken uses.
- fs/nfs/flexfilelayout/flexfilelayout.c
- lib/kunit/string-stream.c (although the preceding vsnprintf() looks like the actual bug).
There is also some very strange code in security/selinus/ima.c - but it may be ok.
In reality the return value of strlcat() isn't really much worse that that
of snprintf().
-- David
>
> So if I would remove strlcat() from appending something to boot_command_line I
> would end up open-coding strlcat(), including the chance for the usual
> off-by-one bugs. Looks like this would be true for nearly all architectures.
>
> Is performance really the only reason to deprecate strlcat()? This seems to be
> a bit questionable to me.
^ permalink raw reply
* Re: Stop false review statements
From: Roman Gushchin @ 2026-05-16 15:49 UTC (permalink / raw)
To: Greg KH
Cc: Konstantin Ryabitsev, Guenter Roeck, Krzysztof Kozlowski,
sashiko-bot, sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree, kfree
In-Reply-To: <2026051631-trolling-juggling-da1c@gregkh>
> On May 16, 2026, at 8:45 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sat, May 16, 2026 at 08:41:43AM -0700, Roman Gushchin wrote:
>>
>>>> On May 16, 2026, at 8:20 AM, Konstantin Ryabitsev <mricon@kernel.org> wrote:
>>>
>>> On Sat, May 16, 2026 at 05:11:28AM -0700, Guenter Roeck wrote:
>>>>> On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
>>>>> What the hell is that:
>>>>>
>>>>> https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
>>>>>
>>>>> As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
>>>>> not a damn human do be able to make such statement. You are a bot, a tool.
>>>>>
>>>>
>>>> Where exactly do the rules say that ? I seem to miss that.
>>>>
>>>> There is a policy document about _contributions_ made by AI, but I don't
>>>> see the one that says that AI agents must not provide Reviewed-by: tags.
>>>
>>> From my perspective, AI agents must NOT use the Reviewed-by tag for the
>>> following reasons:
>>>
>>> - We consider this a "person-trailer" and it implies agency
>>> - Adding yourself to a commit via a trailer is a *binding responsibility* for
>>> the change. A lot of tooling will cc the Reviewed-by addresses on follow-up
>>> messages regarding code in this commit. If the address is bogus or doesn't
>>> go to a developer, this is both wasteful and potentially frustrating.
>>
>> Hi Konstantin!
>>
>> The goal here is to inform maintainers that sashiko has successfully reviewed the patch
>> and there were no findings, otherwise maintainers have to go to the web site and check the status.
>
> That's fine.
>
>> I’m not attached to any specific form of it, I thought Reviewed-by is the most obvious form.
>> And we use Reported-by: tags with various tooling for years.
>
> Reported-by: shows the existance of a problem that some tool found, a
> subtle difference here.
>
>> What do you think is the best form?
>>
>> I’ll pause sending reviewed-by tags until we have a discussion and agreement here.
>
> Just say it in some other text form, that our tools will not pick up.
> Like:
> Tool XXXX reports that all is good:
> https://....
>
> or something like that?
Sure, works for me.
Thanks,
Roman
^ permalink raw reply
* Re: Stop false review statements
From: Greg KH @ 2026-05-16 15:45 UTC (permalink / raw)
To: Roman Gushchin
Cc: Konstantin Ryabitsev, Guenter Roeck, Krzysztof Kozlowski,
sashiko-bot, sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree, kfree
In-Reply-To: <D659E814-069C-439A-B816-1BC383F38E1F@linux.dev>
On Sat, May 16, 2026 at 08:41:43AM -0700, Roman Gushchin wrote:
>
> > On May 16, 2026, at 8:20 AM, Konstantin Ryabitsev <mricon@kernel.org> wrote:
> >
> > On Sat, May 16, 2026 at 05:11:28AM -0700, Guenter Roeck wrote:
> >>> On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
> >>> What the hell is that:
> >>>
> >>> https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
> >>>
> >>> As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
> >>> not a damn human do be able to make such statement. You are a bot, a tool.
> >>>
> >>
> >> Where exactly do the rules say that ? I seem to miss that.
> >>
> >> There is a policy document about _contributions_ made by AI, but I don't
> >> see the one that says that AI agents must not provide Reviewed-by: tags.
> >
> > From my perspective, AI agents must NOT use the Reviewed-by tag for the
> > following reasons:
> >
> > - We consider this a "person-trailer" and it implies agency
> > - Adding yourself to a commit via a trailer is a *binding responsibility* for
> > the change. A lot of tooling will cc the Reviewed-by addresses on follow-up
> > messages regarding code in this commit. If the address is bogus or doesn't
> > go to a developer, this is both wasteful and potentially frustrating.
>
> Hi Konstantin!
>
> The goal here is to inform maintainers that sashiko has successfully reviewed the patch
> and there were no findings, otherwise maintainers have to go to the web site and check the status.
That's fine.
> I’m not attached to any specific form of it, I thought Reviewed-by is the most obvious form.
> And we use Reported-by: tags with various tooling for years.
Reported-by: shows the existance of a problem that some tool found, a
subtle difference here.
> What do you think is the best form?
>
> I’ll pause sending reviewed-by tags until we have a discussion and agreement here.
Just say it in some other text form, that our tools will not pick up.
Like:
Tool XXXX reports that all is good:
https://....
or something like that?
thanks,
greg k-h
^ permalink raw reply
* Re: Stop false review statements
From: Roman Gushchin @ 2026-05-16 15:41 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Guenter Roeck, Krzysztof Kozlowski, sashiko-bot, sashiko-reviews,
sashiko, Linux Kernel Workflows, Linux Kernel Mailing List,
devicetree, kfree
In-Reply-To: <20260516-upbeat-tody-of-feminism-4ab00a@lemur>
> On May 16, 2026, at 8:20 AM, Konstantin Ryabitsev <mricon@kernel.org> wrote:
>
> On Sat, May 16, 2026 at 05:11:28AM -0700, Guenter Roeck wrote:
>>> On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
>>> What the hell is that:
>>>
>>> https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
>>>
>>> As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
>>> not a damn human do be able to make such statement. You are a bot, a tool.
>>>
>>
>> Where exactly do the rules say that ? I seem to miss that.
>>
>> There is a policy document about _contributions_ made by AI, but I don't
>> see the one that says that AI agents must not provide Reviewed-by: tags.
>
> From my perspective, AI agents must NOT use the Reviewed-by tag for the
> following reasons:
>
> - We consider this a "person-trailer" and it implies agency
> - Adding yourself to a commit via a trailer is a *binding responsibility* for
> the change. A lot of tooling will cc the Reviewed-by addresses on follow-up
> messages regarding code in this commit. If the address is bogus or doesn't
> go to a developer, this is both wasteful and potentially frustrating.
Hi Konstantin!
The goal here is to inform maintainers that sashiko has successfully reviewed the patch
and there were no findings, otherwise maintainers have to go to the web site and check the status.
I’m not attached to any specific form of it, I thought Reviewed-by is the most obvious form.
And we use Reported-by: tags with various tooling for years.
What do you think is the best form?
I’ll pause sending reviewed-by tags until we have a discussion and agreement here.
Thanks
^ permalink raw reply
* Re: Stop false review statements
From: Greg KH @ 2026-05-16 15:36 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Guenter Roeck, Krzysztof Kozlowski, sashiko-bot, sashiko-reviews,
sashiko, Linux Kernel Workflows, Linux Kernel Mailing List,
devicetree@vger.kernel.org, kfree
In-Reply-To: <20260516-upbeat-tody-of-feminism-4ab00a@lemur>
On Sat, May 16, 2026 at 11:20:33AM -0400, Konstantin Ryabitsev wrote:
> On Sat, May 16, 2026 at 05:11:28AM -0700, Guenter Roeck wrote:
> > On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
> > > What the hell is that:
> > >
> > > https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
> > >
> > > As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
> > > not a damn human do be able to make such statement. You are a bot, a tool.
> > >
> >
> > Where exactly do the rules say that ? I seem to miss that.
> >
> > There is a policy document about _contributions_ made by AI, but I don't
> > see the one that says that AI agents must not provide Reviewed-by: tags.
>
> >From my perspective, AI agents must NOT use the Reviewed-by tag for the
> following reasons:
>
> - We consider this a "person-trailer" and it implies agency
> - Adding yourself to a commit via a trailer is a *binding responsibility* for
> the change. A lot of tooling will cc the Reviewed-by addresses on follow-up
> messages regarding code in this commit. If the address is bogus or doesn't
> go to a developer, this is both wasteful and potentially frustrating.
I agree, any sort of "automated" tool shouldn't be adding these types of
tags.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/3] Doc: deprecated.rst: add strlcat()
From: Heiko Carstens @ 2026-05-16 15:28 UTC (permalink / raw)
To: Kees Cook
Cc: Manuel Ebner, Andy Shevchenko, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Geert Uytterhoeven, David Laight, Randy Dunlap, Jani Nikula,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION,
open list
In-Reply-To: <202605140931.913048A68B@keescook>
On Thu, May 14, 2026 at 09:31:46AM -0700, Kees Cook wrote:
> On Thu, May 14, 2026 at 06:26:53PM +0200, Manuel Ebner wrote:
> > add strlcat and alternatives
> >
> > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > ---
> > Documentation/process/deprecated.rst | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> > index fed56864d036..06e802f4bbfd 100644
> > --- a/Documentation/process/deprecated.rst
> > +++ b/Documentation/process/deprecated.rst
> > @@ -153,6 +153,13 @@ used, and the destinations should be marked with the `__nonstring
> > attribute to avoid future compiler warnings. For cases still needing
> > NUL-padding, strtomem_pad() can be used.
> >
> > +strlcat()
> > +---------
> > +strlcat() must re-scan the destination string from the beginning on each
> > +call (O(n^2) behavior). Alternatives are seq_buf_puts() and seq_buf_printf().
> > +snprintf(), scnprintf() and sysfs_emit() are possible aswell, but the adoption
> > +of the arguments needs to be taken care off.
> > +
>
> How about just:
>
> strlcat() must re-scan the destination string from the beginning on each
> call (O(n^2) behavior). Use the seq_buf API or similar instead.
seq_buf API for appending something to e.g. boot_command_line seems to be odd,
since boot_command_line is usually "just there" (depending on architecture and
boot loader).
So if I would remove strlcat() from appending something to boot_command_line I
would end up open-coding strlcat(), including the chance for the usual
off-by-one bugs. Looks like this would be true for nearly all architectures.
Is performance really the only reason to deprecate strlcat()? This seems to be
a bit questionable to me.
^ permalink raw reply
* Re: Stop false review statements
From: Konstantin Ryabitsev @ 2026-05-16 15:20 UTC (permalink / raw)
To: Guenter Roeck
Cc: Krzysztof Kozlowski, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List,
devicetree@vger.kernel.org, kfree
In-Reply-To: <fcc4b719-2696-4f31-bac4-6c07f8ddec47@roeck-us.net>
On Sat, May 16, 2026 at 05:11:28AM -0700, Guenter Roeck wrote:
> On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
> > What the hell is that:
> >
> > https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
> >
> > As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
> > not a damn human do be able to make such statement. You are a bot, a tool.
> >
>
> Where exactly do the rules say that ? I seem to miss that.
>
> There is a policy document about _contributions_ made by AI, but I don't
> see the one that says that AI agents must not provide Reviewed-by: tags.
From my perspective, AI agents must NOT use the Reviewed-by tag for the
following reasons:
- We consider this a "person-trailer" and it implies agency
- Adding yourself to a commit via a trailer is a *binding responsibility* for
the change. A lot of tooling will cc the Reviewed-by addresses on follow-up
messages regarding code in this commit. If the address is bogus or doesn't
go to a developer, this is both wasteful and potentially frustrating.
-K
^ permalink raw reply
* Re: [PATCH] docs: submitting-patches: Clarify that in English "reviewer" is a person
From: Vlastimil Babka (SUSE) @ 2026-05-16 14:39 UTC (permalink / raw)
To: Krzysztof Kozlowski, Jonathan Corbet, Shuah Khan, workflows,
linux-doc, linux-kernel
Cc: Greg Kroah-Hartman, Andrew Morton, David Hildenbrand,
Linus Torvalds, Guenter Roeck
In-Reply-To: <20260516123846.63413-2-krzysztof.kozlowski@oss.qualcomm.com>
On 5/16/26 14:38, Krzysztof Kozlowski wrote:
> Common understanding of word "Reviewer" is: a person performing a review
> work [1]. Tools are not persons, thus cannot be reviewers in this term.
> Also tools cannot make statements ("A Reviewed-by tag is a statement of
> opinion"), since making a statement needs some sort of conscious mind.
>
> Our docs already clearly mark that "Reviewed-by" must come from a
> person:
>
> - "By offering my Reviewed-by: tag, I state that:"
>
> Usage of first person "I" and word "state"
>
> - "A Reviewed-by tag is *a statement of opinion* that the patch is an
> appropriate modification of the kernel without any remaining serious"
>
> Only a person can make a statement of opinion.
>
> - "Any interested reviewer (who has done the work) can offer a
> Reviewed-by"
>
> A person can offer a tag thus above does not grant the tool
> permission to offer a tag.
>
> However this is not enough and apparently English is not that precise,
> so let's clarify that only a person can state the "Reviewer's statement
> of oversight".
>
> Link: https://en.wiktionary.org/wiki/reviewer [1]
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
I agree with the intent that the tag is for people (whether they use a tool
or not to help them). We also don't put "Tested-by: kernel test robot" or
syzkaller on every commit that they test and find no bugs. Review is also
not just about absence of bugs, but agreeing with the larger design and
whether the change makes sense to do in the first place.
So whether that's achieved with this particular wording or differently,
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
>
> ---
>
> I find it silly to need to describe English, but it seems it is needed.
>
> https://lore.kernel.org/all/fd3b2ca7-4d64-4c4b-98a3-7d3285fa6826@roeck-us.net/
> ---
> Documentation/process/submitting-patches.rst | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index d7290e208e72..a989de43f3db 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -581,10 +581,10 @@ By offering my Reviewed-by: tag, I state that:
>
> A Reviewed-by tag is a statement of opinion that the patch is an
> appropriate modification of the kernel without any remaining serious
> -technical issues. Any interested reviewer (who has done the work) can
> -offer a Reviewed-by tag for a patch. This tag serves to give credit to
> -reviewers and to inform maintainers of the degree of review which has been
> -done on the patch. Reviewed-by: tags, when supplied by reviewers known to
> +technical issues. Any interested reviewer (who has done the work and is a
> +person) can offer a Reviewed-by tag for a patch. This tag serves to give
> +credit to reviewers and to inform maintainers of the degree of review which has
> +been done on the patch. Reviewed-by: tags, when supplied by reviewers known to
> understand the subject area and to perform thorough reviews, will normally
> increase the likelihood of your patch getting into the kernel.
>
^ permalink raw reply
* Re: Stop false review statements
From: Krzysztof Kozlowski @ 2026-05-16 13:45 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Guenter Roeck, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List,
devicetree@vger.kernel.org, kfree
In-Reply-To: <20260516132407.GA163589@killaraus.ideasonboard.com>
On 16/05/2026 15:24, Laurent Pinchart wrote:
> On Sat, May 16, 2026 at 02:29:15PM +0200, Krzysztof Kozlowski wrote:
>> On 16/05/2026 14:23, Guenter Roeck wrote:
>>> On 5/16/26 05:16, Krzysztof Kozlowski wrote:
>>>> On 16/05/2026 14:11, Guenter Roeck wrote:
>>>>> On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
>>>>>> What the hell is that:
>>>>>>
>>>>>> https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
>>>>>>
>>>>>> As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
>>>>>> not a damn human do be able to make such statement. You are a bot, a tool.
>>>>>>
>>>>>
>>>>> Where exactly do the rules say that ? I seem to miss that.
>>>>>
>>>>> There is a policy document about _contributions_ made by AI, but I don't
>>>>> see the one that says that AI agents must not provide Reviewed-by: tags.
>>>>
>>>> Quotes from the existing policy:
>>>>
>>>> 1. "By offering my Reviewed-by: tag, I state that:"
>>>>
>>>> Tool cannot use first person "I". Tool cannot "state that".
>>>>
>>>> 2. "A Reviewed-by tag is *a statement of opinion* that the patch is an
>>>> appropriate modification of the kernel without any remaining serious"
>>>>
>>>> Tool cannot make a statement of opinion.
>>>>
>>>> 3. "Any interested reviewer (who has done the work) can offer a
>>>> Reviewed-by".
>>>>
>>>> Tool is not a reviewer as a person, thus above does not grant the tool
>>>> permission to offer a tag.
>>>
>>> I'd like to see that explicitly spelled out. Until then it is your opinion.
>>
>> It is not an opinion. It is written. I gave you quotes.
>>
>> Do you want to spell the rules of English language? That tool is not a
>> person?
>>
>> Shall I send the patch like:
>>
>> Any interested reviewer (who has done the work) can offer a
>> Reviewed-by.
>> +In English "reviewer" is a person [1].
>> + [1] https://en.wiktionary.org/wiki/reviewer
>>
>> Seriously, you expect to document the English language?
>>
>>>>>> Stop faking tags.
>>>>>>
>>>>>> And really, considering how many false positives Sashiko produces, how
>>>>>> poor review comments it gives, how many misleading comments, it's
>>>>>> unacceptable to me to consider that a review.
>>>>>>
>>>>>> Amount of useless noise Sashiko produces already changed my mind how
>>>>>> useful that tool is.
>
> Note this isn't en entirely new situation. As a maintainer, you know how
> much you trust each reviewer. You will consider some R-b tags as a sign
> you don't even have to look at a patch, and will completely ignore some
> others. There's a whole continuum in the middle. In some ways, reviews
> by an LLM are similar. You will trust them or not trust them.
>
> Except they're also very different.
>
> The kernel needs more skilled reviewers (I don't think this is a
> controversial statement). We can't expect all newcomers to start with
> extensive experience from day one, so there's a learning curve. I
> believe it's fine for more junior reviewers to send R-b tags even if
> they miss some issue, as long as they genuinely try and improve (and, in
> some unfortunate cases, decide to leave if patch review turns out not to
> be for them). Those R-b tags may feel like a bit of noise in the
> beginning, but that's compensated by their value increasing over time.
Yes, I agree. Reviews from inexperienced people are sometimes fruitless
or pointless per actual value they bring, but they allow a person
(again: person) to grow in the community with a credits being the reward.
>
> Bot reviews are not the same. Not only are they generated at a much
> larger scale than human reviews, they also won't learn from feedback you
> give them. Sure, the tools may be improved when cases of false positives
> are identified, and new LLMs may be trained with more (and better ?)
> data to improve the output, but they won't learn from the interactions.
>
> How much value a maintainer sees in those reviews is up to individual
> maintainers. I will personally not consider a R-b tag from an LLM to
> mean that a patch is ready to be merged (and I believe you won't
> either). As such, I think that a R-b from an LLM is misleading and
> doesn't provide good value. At best it's free advertising for company
> making closed-source tools, which I don't think we should encourage.
That's different aspect than I raised. I agree with above approach but
it is more subjective.
What I brought is object: our docs clearly state that reviewer can offer
reviewed-by tag. They do not allow non-reviewers to offer a tag and
English is clear on that - only a person is a reviewer.
Dog is not a reviewer.
Hammer is not a reviewer.
Tool is not a reviewer.
Guenter did not bring any counter arguments that our docs ALLOW
non-person to provide a reviewed-by tag. I brought that arguments as
excerpt from our documented policy.
Best regards,
Krzysztof
^ permalink raw reply
* Re: Stop false review statements
From: Laurent Pinchart @ 2026-05-16 13:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Guenter Roeck, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List,
devicetree@vger.kernel.org, kfree
In-Reply-To: <b5f2a21a-9530-4efe-aed5-cc96aab74e88@kernel.org>
On Sat, May 16, 2026 at 02:29:15PM +0200, Krzysztof Kozlowski wrote:
> On 16/05/2026 14:23, Guenter Roeck wrote:
> > On 5/16/26 05:16, Krzysztof Kozlowski wrote:
> >> On 16/05/2026 14:11, Guenter Roeck wrote:
> >>> On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
> >>>> What the hell is that:
> >>>>
> >>>> https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
> >>>>
> >>>> As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
> >>>> not a damn human do be able to make such statement. You are a bot, a tool.
> >>>>
> >>>
> >>> Where exactly do the rules say that ? I seem to miss that.
> >>>
> >>> There is a policy document about _contributions_ made by AI, but I don't
> >>> see the one that says that AI agents must not provide Reviewed-by: tags.
> >>
> >> Quotes from the existing policy:
> >>
> >> 1. "By offering my Reviewed-by: tag, I state that:"
> >>
> >> Tool cannot use first person "I". Tool cannot "state that".
> >>
> >> 2. "A Reviewed-by tag is *a statement of opinion* that the patch is an
> >> appropriate modification of the kernel without any remaining serious"
> >>
> >> Tool cannot make a statement of opinion.
> >>
> >> 3. "Any interested reviewer (who has done the work) can offer a
> >> Reviewed-by".
> >>
> >> Tool is not a reviewer as a person, thus above does not grant the tool
> >> permission to offer a tag.
> >
> > I'd like to see that explicitly spelled out. Until then it is your opinion.
>
> It is not an opinion. It is written. I gave you quotes.
>
> Do you want to spell the rules of English language? That tool is not a
> person?
>
> Shall I send the patch like:
>
> Any interested reviewer (who has done the work) can offer a
> Reviewed-by.
> +In English "reviewer" is a person [1].
> + [1] https://en.wiktionary.org/wiki/reviewer
>
> Seriously, you expect to document the English language?
>
> >>>> Stop faking tags.
> >>>>
> >>>> And really, considering how many false positives Sashiko produces, how
> >>>> poor review comments it gives, how many misleading comments, it's
> >>>> unacceptable to me to consider that a review.
> >>>>
> >>>> Amount of useless noise Sashiko produces already changed my mind how
> >>>> useful that tool is.
Note this isn't en entirely new situation. As a maintainer, you know how
much you trust each reviewer. You will consider some R-b tags as a sign
you don't even have to look at a patch, and will completely ignore some
others. There's a whole continuum in the middle. In some ways, reviews
by an LLM are similar. You will trust them or not trust them.
Except they're also very different.
The kernel needs more skilled reviewers (I don't think this is a
controversial statement). We can't expect all newcomers to start with
extensive experience from day one, so there's a learning curve. I
believe it's fine for more junior reviewers to send R-b tags even if
they miss some issue, as long as they genuinely try and improve (and, in
some unfortunate cases, decide to leave if patch review turns out not to
be for them). Those R-b tags may feel like a bit of noise in the
beginning, but that's compensated by their value increasing over time.
Bot reviews are not the same. Not only are they generated at a much
larger scale than human reviews, they also won't learn from feedback you
give them. Sure, the tools may be improved when cases of false positives
are identified, and new LLMs may be trained with more (and better ?)
data to improve the output, but they won't learn from the interactions.
How much value a maintainer sees in those reviews is up to individual
maintainers. I will personally not consider a R-b tag from an LLM to
mean that a patch is ready to be merged (and I believe you won't
either). As such, I think that a R-b from an LLM is misleading and
doesn't provide good value. At best it's free advertising for company
making closed-source tools, which I don't think we should encourage.
If some maintainers want LLM reviews and want to act on them, that's
their personal prerogative. They're free to decide on how much value
they see in those reviews, as well as on whether or not they consider
usage of those tools compatible with FOSS ethics. Those are personal
decisions. However, given that the ethical decision is personal, I am
strongly against forcing patch authors to act on automated LLM review.
> >>> We seem to have completely different experiences. Yes, it does produce
> >>> false positives, just like humans do. However, I have seen it find many
> >>> real bugs, including many in patches which already had Reviewed-by: tags
> >>> from (presumably) human reviewers.
> >>
> >> Of course it finds bugs. But it also produces - roughly - 80-90% false
> >> positives, completely useless.
> >>
> >
> > Really ? The ones I have seen are - roughly, to use the same term - 80-90%
> > true positives. Maybe you should explicitly ask for no Sashiko reviews in
> > your scope of responsibility.
>
> I already sent a patch to stop receiving all these emails and I stopped
> reading them completely, when fetched via b4 for review in mutt workflow.
>
> But this is not the point.
>
> Our docs clearly state what Reviewed-by means, regardless of the quality
> of the actual review. Poor quality is just another reason, less
> important, though.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] docs: submitting-patches: Clarify that in English "reviewer" is a person
From: Krzysztof Kozlowski @ 2026-05-16 12:38 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski, Greg Kroah-Hartman, Vlastimil Babka,
Andrew Morton, David Hildenbrand, Linus Torvalds
Common understanding of word "Reviewer" is: a person performing a review
work [1]. Tools are not persons, thus cannot be reviewers in this term.
Also tools cannot make statements ("A Reviewed-by tag is a statement of
opinion"), since making a statement needs some sort of conscious mind.
Our docs already clearly mark that "Reviewed-by" must come from a
person:
- "By offering my Reviewed-by: tag, I state that:"
Usage of first person "I" and word "state"
- "A Reviewed-by tag is *a statement of opinion* that the patch is an
appropriate modification of the kernel without any remaining serious"
Only a person can make a statement of opinion.
- "Any interested reviewer (who has done the work) can offer a
Reviewed-by"
A person can offer a tag thus above does not grant the tool
permission to offer a tag.
However this is not enough and apparently English is not that precise,
so let's clarify that only a person can state the "Reviewer's statement
of oversight".
Link: https://en.wiktionary.org/wiki/reviewer [1]
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I find it silly to need to describe English, but it seems it is needed.
https://lore.kernel.org/all/fd3b2ca7-4d64-4c4b-98a3-7d3285fa6826@roeck-us.net/
---
Documentation/process/submitting-patches.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index d7290e208e72..a989de43f3db 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -581,10 +581,10 @@ By offering my Reviewed-by: tag, I state that:
A Reviewed-by tag is a statement of opinion that the patch is an
appropriate modification of the kernel without any remaining serious
-technical issues. Any interested reviewer (who has done the work) can
-offer a Reviewed-by tag for a patch. This tag serves to give credit to
-reviewers and to inform maintainers of the degree of review which has been
-done on the patch. Reviewed-by: tags, when supplied by reviewers known to
+technical issues. Any interested reviewer (who has done the work and is a
+person) can offer a Reviewed-by tag for a patch. This tag serves to give
+credit to reviewers and to inform maintainers of the degree of review which has
+been done on the patch. Reviewed-by: tags, when supplied by reviewers known to
understand the subject area and to perform thorough reviews, will normally
increase the likelihood of your patch getting into the kernel.
--
2.51.0
^ permalink raw reply related
* Re: Stop false review statements
From: Krzysztof Kozlowski @ 2026-05-16 12:29 UTC (permalink / raw)
To: Guenter Roeck
Cc: sashiko-bot, sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree@vger.kernel.org, kfree
In-Reply-To: <fd3b2ca7-4d64-4c4b-98a3-7d3285fa6826@roeck-us.net>
On 16/05/2026 14:23, Guenter Roeck wrote:
> On 5/16/26 05:16, Krzysztof Kozlowski wrote:
>> On 16/05/2026 14:11, Guenter Roeck wrote:
>>> On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
>>>> What the hell is that:
>>>>
>>>> https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
>>>>
>>>> As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
>>>> not a damn human do be able to make such statement. You are a bot, a tool.
>>>>
>>>
>>> Where exactly do the rules say that ? I seem to miss that.
>>>
>>> There is a policy document about _contributions_ made by AI, but I don't
>>> see the one that says that AI agents must not provide Reviewed-by: tags.
>>
>> Quotes from the existing policy:
>>
>> 1. "By offering my Reviewed-by: tag, I state that:"
>>
>> Tool cannot use first person "I". Tool cannot "state that".
>>
>> 2. "A Reviewed-by tag is *a statement of opinion* that the patch is an
>> appropriate modification of the kernel without any remaining serious"
>>
>> Tool cannot make a statement of opinion.
>>
>> 3. "Any interested reviewer (who has done the work) can offer a
>> Reviewed-by".
>>
>> Tool is not a reviewer as a person, thus above does not grant the tool
>> permission to offer a tag.
>>
>
> I'd like to see that explicitly spelled out. Until then it is your opinion.
It is not an opinion. It is written. I gave you quotes.
Do you want to spell the rules of English language? That tool is not a
person?
Shall I send the patch like:
Any interested reviewer (who has done the work) can offer a
Reviewed-by.
+In English "reviewer" is a person [1].
+ [1] https://en.wiktionary.org/wiki/reviewer
Seriously, you expect to document the English language?
>
>>>
>>>> Stop faking tags.
>>>>
>>>> And really, considering how many false positives Sashiko produces, how
>>>> poor review comments it gives, how many misleading comments, it's
>>>> unacceptable to me to consider that a review.
>>>>
>>>> Amount of useless noise Sashiko produces already changed my mind how
>>>> useful that tool is.
>>>
>>> We seem to have completely different experiences. Yes, it does produce
>>> false positives, just like humans do. However, I have seen it find many
>>> real bugs, including many in patches which already had Reviewed-by: tags
>>> from (presumably) human reviewers.
>>
>> Of course it finds bugs. But it also produces - roughly - 80-90% false
>> positives, completely useless.
>>
>
> Really ? The ones I have seen are - roughly, to use the same term - 80-90%
> true positives. Maybe you should explicitly ask for no Sashiko reviews in
> your scope of responsibility.
I already sent a patch to stop receiving all these emails and I stopped
reading them completely, when fetched via b4 for review in mutt workflow.
But this is not the point.
Our docs clearly state what Reviewed-by means, regardless of the quality
of the actual review. Poor quality is just another reason, less
important, though.
Best regards,
Krzysztof
^ permalink raw reply
* Re: Stop false review statements
From: Guenter Roeck @ 2026-05-16 12:23 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: sashiko-bot, sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree@vger.kernel.org, kfree
In-Reply-To: <221cc52e-9918-43ea-b196-622a8cc6db05@kernel.org>
On 5/16/26 05:16, Krzysztof Kozlowski wrote:
> On 16/05/2026 14:11, Guenter Roeck wrote:
>> On Sat, May 16, 2026 at 10:05:02AM +0200, Krzysztof Kozlowski wrote:
>>> What the hell is that:
>>>
>>> https://lore.kernel.org/all/20260515190707.033BDC2BCB0@smtp.kernel.org/
>>>
>>> As a bot you CANNOT MAKE a Reviewer's statement of oversight. You are
>>> not a damn human do be able to make such statement. You are a bot, a tool.
>>>
>>
>> Where exactly do the rules say that ? I seem to miss that.
>>
>> There is a policy document about _contributions_ made by AI, but I don't
>> see the one that says that AI agents must not provide Reviewed-by: tags.
>
> Quotes from the existing policy:
>
> 1. "By offering my Reviewed-by: tag, I state that:"
>
> Tool cannot use first person "I". Tool cannot "state that".
>
> 2. "A Reviewed-by tag is *a statement of opinion* that the patch is an
> appropriate modification of the kernel without any remaining serious"
>
> Tool cannot make a statement of opinion.
>
> 3. "Any interested reviewer (who has done the work) can offer a
> Reviewed-by".
>
> Tool is not a reviewer as a person, thus above does not grant the tool
> permission to offer a tag.
>
I'd like to see that explicitly spelled out. Until then it is your opinion.
>>
>>> Stop faking tags.
>>>
>>> And really, considering how many false positives Sashiko produces, how
>>> poor review comments it gives, how many misleading comments, it's
>>> unacceptable to me to consider that a review.
>>>
>>> Amount of useless noise Sashiko produces already changed my mind how
>>> useful that tool is.
>>
>> We seem to have completely different experiences. Yes, it does produce
>> false positives, just like humans do. However, I have seen it find many
>> real bugs, including many in patches which already had Reviewed-by: tags
>> from (presumably) human reviewers.
>
> Of course it finds bugs. But it also produces - roughly - 80-90% false
> positives, completely useless.
>
Really ? The ones I have seen are - roughly, to use the same term - 80-90%
true positives. Maybe you should explicitly ask for no Sashiko reviews in
your scope of responsibility.
Thanks,
Guenter
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox