* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 15:07 ` Greg KH
@ 2026-07-02 15:13 ` Jonathan Corbet
2026-07-02 15:20 ` Lorenzo Stoakes
2026-07-02 18:46 ` Andreas Dilger
2026-07-02 15:15 ` Lorenzo Stoakes
` (3 subsequent siblings)
4 siblings, 2 replies; 43+ messages in thread
From: Jonathan Corbet @ 2026-07-02 15:13 UTC (permalink / raw)
To: Greg KH, Jeff Layton
Cc: Linus Torvalds, Justin Stitt, Lorenzo Stoakes, Laurent Pinchart,
Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
Greg KH <gregkh@linuxfoundation.org> writes:
> On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
>> We've had this requirement in place in the Documentation for several
>> months, but it's becoming clear that the signal to noise ratio from this
>> is quite low.
>>
>> 1/ It's not universally followed. While many people do try to attribute
>> the LLMs in good faith, not everyone does for various reasons.
>
> Then let's move to get people to follow it.
FWIW, in my experience, simple ignorance of the rules is one of the
biggest reasons why so many people fail to follow them. When I've asked
docs contributors about the source of their work, they tend to come
clean, apologize, and add the tags going forward.
jon
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 15:13 ` Jonathan Corbet
@ 2026-07-02 15:20 ` Lorenzo Stoakes
2026-07-02 18:46 ` Andreas Dilger
1 sibling, 0 replies; 43+ messages in thread
From: Lorenzo Stoakes @ 2026-07-02 15:20 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Greg KH, Jeff Layton, Linus Torvalds, Justin Stitt,
Laurent Pinchart, Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Thu, Jul 02, 2026 at 09:13:51AM -0600, Jonathan Corbet wrote:
> Greg KH <gregkh@linuxfoundation.org> writes:
>
> > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> >> We've had this requirement in place in the Documentation for several
> >> months, but it's becoming clear that the signal to noise ratio from this
> >> is quite low.
> >>
> >> 1/ It's not universally followed. While many people do try to attribute
> >> the LLMs in good faith, not everyone does for various reasons.
> >
> > Then let's move to get people to follow it.
>
> FWIW, in my experience, simple ignorance of the rules is one of the
> biggest reasons why so many people fail to follow them. When I've asked
> docs contributors about the source of their work, they tend to come
> clean, apologize, and add the tags going forward.
I also feel that repeatedly establishing boundaries like this (in as civil
and reasonable way as possible) can help establish the 'done thing'.
We will probably still experience a great deal of unattributed patches, and
I think over time we'll have to figure out a way to deal with that, but
there's certainly a cohort who can be reached, and it's beneficial to do
so.
It also makes it easier to enforce with those who don't play nice - 'here
are the rules, look over here, and look at these patches' etc.
With no rules at all it becomes far harder to enforce anything.
>
> jon
Thanks, Lorenzo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 15:13 ` Jonathan Corbet
2026-07-02 15:20 ` Lorenzo Stoakes
@ 2026-07-02 18:46 ` Andreas Dilger
2026-07-03 2:57 ` Theodore Tso
1 sibling, 1 reply; 43+ messages in thread
From: Andreas Dilger @ 2026-07-02 18:46 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Greg KH, Jeff Layton, Linus Torvalds, Justin Stitt,
Lorenzo Stoakes, Laurent Pinchart, Carlos Maiolino,
Jakub Kicinski, Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, David Hildenbrand, Vlastimil Babka,
Christian Brauner (Amutable), workflows, linux-doc, linux-kernel,
linux-fsdevel
On Jul 2, 2026, at 09:13, Jonathan Corbet <corbet@lwn.net> wrote:
>
> Greg KH <gregkh@linuxfoundation.org> writes:
>
>> On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
>>> We've had this requirement in place in the Documentation for several
>>> months, but it's becoming clear that the signal to noise ratio from this
>>> is quite low.
>>>
>>> 1/ It's not universally followed. While many people do try to attribute
>>> the LLMs in good faith, not everyone does for various reasons.
>>
>> Then let's move to get people to follow it.
>
> FWIW, in my experience, simple ignorance of the rules is one of the
> biggest reasons why so many people fail to follow them. When I've asked
> docs contributors about the source of their work, they tend to come
> clean, apologize, and add the tags going forward.
It would make sense IMHO to address the ignorance in the most expedient manner,
namely by telling the *LLM itself* to add this tag when it generates the commit
message and/or reviews the code.
This could be achieved by adding a statement in "AGENTS.md" in the root of the
source tree to this effect, or telling the agent to reference and follow rules
in Documentation/process/coding-assistants.rst regarding the Assisted-by: tag.
Cheers, Andreas
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 18:46 ` Andreas Dilger
@ 2026-07-03 2:57 ` Theodore Tso
2026-07-03 11:50 ` Jori Koolstra
2026-07-03 16:12 ` Andreas Dilger
0 siblings, 2 replies; 43+ messages in thread
From: Theodore Tso @ 2026-07-03 2:57 UTC (permalink / raw)
To: Andreas Dilger
Cc: Jonathan Corbet, Greg KH, Jeff Layton, Linus Torvalds,
Justin Stitt, Lorenzo Stoakes, Laurent Pinchart, Carlos Maiolino,
Jakub Kicinski, Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, David Hildenbrand, Vlastimil Babka,
Christian Brauner (Amutable), workflows, linux-doc, linux-kernel,
linux-fsdevel
On Thu, Jul 02, 2026 at 12:46:19PM -0500, Andreas Dilger wrote:
> It would make sense IMHO to address the ignorance in the most expedient manner,
> namely by telling the *LLM itself* to add this tag when it generates the commit
> message and/or reviews the code.
>
> This could be achieved by adding a statement in "AGENTS.md" in the root of the
> source tree to this effect, or telling the agent to reference and follow rules
> in Documentation/process/coding-assistants.rst regarding the Assisted-by: tag.
This presupposes a particular workflow where the developer allows the
LLM to generate git commits. I don't do that. I'll ask the LLM to
modify the code, but then I'll generally fix it up --- very often by
hand because I can edit the sources than entering a prompt and waiting
for the LLM to figure out how to make the change. I'll often run the
test cases myself, since if it takes 24 hours of VM time, and 2 hours
of wall clock time, I'm going to kick off the regression tests myself,
and verify the test results.
And I almost always write the commit description myself. So when I
say, "Assisted-by" it literally is "Assisted by". It is not "vibe
coded where the LLM generates thousands of lines of code that the
human being doesn't understand before sending ta pull request." And
that's probably why you'll see people asserting that LLM generated
code can't possibly be accepted due to copyright reasons. There's a
big difference between asking an LLM to modify already existing code
to add a feature, or to fix a bug, and to vibe code a new OS from
scratch. One is far less likely to be a copyright violation than the
other.
- Ted
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 2:57 ` Theodore Tso
@ 2026-07-03 11:50 ` Jori Koolstra
2026-07-03 16:12 ` Andreas Dilger
1 sibling, 0 replies; 43+ messages in thread
From: Jori Koolstra @ 2026-07-03 11:50 UTC (permalink / raw)
To: Theodore Tso, Andreas Dilger
Cc: Jonathan Corbet, Greg KH, Jeff Layton, Linus Torvalds,
Justin Stitt, Lorenzo Stoakes, Laurent Pinchart, Carlos Maiolino,
Jakub Kicinski, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, David Hildenbrand, Vlastimil Babka,
Christian Brauner (Amutable), workflows, linux-doc, linux-kernel,
linux-fsdevel
> Op 03-07-2026 04:57 CEST schreef Theodore Tso <tytso@mit.edu>:
>
>
> On Thu, Jul 02, 2026 at 12:46:19PM -0500, Andreas Dilger wrote:
> > It would make sense IMHO to address the ignorance in the most expedient manner,
> > namely by telling the *LLM itself* to add this tag when it generates the commit
> > message and/or reviews the code.
> >
> > This could be achieved by adding a statement in "AGENTS.md" in the root of the
> > source tree to this effect, or telling the agent to reference and follow rules
> > in Documentation/process/coding-assistants.rst regarding the Assisted-by: tag.
>
> This presupposes a particular workflow where the developer allows the
> LLM to generate git commits. I don't do that. I'll ask the LLM to
> modify the code, but then I'll generally fix it up --- very often by
> hand because I can edit the sources than entering a prompt and waiting
> for the LLM to figure out how to make the change. I'll often run the
> test cases myself, since if it takes 24 hours of VM time, and 2 hours
> of wall clock time, I'm going to kick off the regression tests myself,
> and verify the test results.
>
> And I almost always write the commit description myself. So when I
> say, "Assisted-by" it literally is "Assisted by". It is not "vibe
> coded where the LLM generates thousands of lines of code that the
> human being doesn't understand before sending ta pull request." And
> that's probably why you'll see people asserting that LLM generated
> code can't possibly be accepted due to copyright reasons. There's a
> big difference between asking an LLM to modify already existing code
> to add a feature, or to fix a bug, and to vibe code a new OS from
> scratch. One is far less likely to be a copyright violation than the
> other.
>
> - Ted
Just curious if you know about any quantifiable insight into this. I do know
that the issues also plays up in smaller requests. I once asked an LLM to
give me boilerplate for a FUSE fs, and it took almost verbatim the example
hello.c from the repo (which I only recognized because I had looked at that code)
but stripped the copyright info. And this is only like 100 lines of code or so.
Best,
Jori.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 2:57 ` Theodore Tso
2026-07-03 11:50 ` Jori Koolstra
@ 2026-07-03 16:12 ` Andreas Dilger
1 sibling, 0 replies; 43+ messages in thread
From: Andreas Dilger @ 2026-07-03 16:12 UTC (permalink / raw)
To: Theodore Tso
Cc: Jonathan Corbet, Greg KH, Jeff Layton, Linus Torvalds,
Justin Stitt, Lorenzo Stoakes, Laurent Pinchart, Carlos Maiolino,
Jakub Kicinski, Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, David Hildenbrand, Vlastimil Babka,
Christian Brauner (Amutable), workflows, linux-doc, linux-kernel,
linux-fsdevel
On Jul 2, 2026, at 20:57, Theodore Tso <tytso@mit.edu> wrote:
>
> On Thu, Jul 02, 2026 at 12:46:19PM -0500, Andreas Dilger wrote:
>> It would make sense IMHO to address the ignorance in the most expedient manner,
>> namely by telling the *LLM itself* to add this tag when it generates the commit
>> message and/or reviews the code.
>>
>> This could be achieved by adding a statement in "AGENTS.md" in the root of the
>> source tree to this effect, or telling the agent to reference and follow rules
>> in Documentation/process/coding-assistants.rst regarding the Assisted-by: tag.
>
> This presupposes a particular workflow where the developer allows the
> LLM to generate git commits. I don't do that. I'll ask the LLM to
> modify the code, but then I'll generally fix it up --- very often by
> hand because I can edit the sources than entering a prompt and waiting
> for the LLM to figure out how to make the change. I'll often run the
> test cases myself, since if it takes 24 hours of VM time, and 2 hours
> of wall clock time, I'm going to kick off the regression tests myself,
> and verify the test results.
Sure, and that holds true for many kernel developers, myself included.
I don't think you or any of the senior maintainers are the audience.
The point of my comment is that this is more likely to help contributors
who do *not* know/follow standard development practices and are more
likely to contribute AI-coded patches, which is AFAICS the main issue
in this discussion.
Also, the effort of doing so is very minimal and has no real downside.
Having the AI contribution policy clearly spelled out where an AI agent
can find it can only have a positive effect, even if not always followed.
Cheers, Andreas
> And I almost always write the commit description myself. So when I
> say, "Assisted-by" it literally is "Assisted by". It is not "vibe
> coded where the LLM generates thousands of lines of code that the
> human being doesn't understand before sending ta pull request." And
> that's probably why you'll see people asserting that LLM generated
> code can't possibly be accepted due to copyright reasons. There's a
> big difference between asking an LLM to modify already existing code
> to add a feature, or to fix a bug, and to vibe code a new OS from
> scratch. One is far less likely to be a copyright violation than the
> other.
>
> - Ted
Cheers, Andreas
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 15:07 ` Greg KH
2026-07-02 15:13 ` Jonathan Corbet
@ 2026-07-02 15:15 ` Lorenzo Stoakes
2026-07-02 15:33 ` Jori Koolstra
` (2 subsequent siblings)
4 siblings, 0 replies; 43+ messages in thread
From: Lorenzo Stoakes @ 2026-07-02 15:15 UTC (permalink / raw)
To: Greg KH
Cc: Jeff Layton, Linus Torvalds, Jonathan Corbet, Justin Stitt,
Laurent Pinchart, Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Thu, Jul 02, 2026 at 05:07:03PM +0200, Greg KH wrote:
> On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > We've had this requirement in place in the Documentation for several
> > months, but it's becoming clear that the signal to noise ratio from this
> > is quite low.
> >
> > 1/ It's not universally followed. While many people do try to attribute
> > the LLMs in good faith, not everyone does for various reasons.
>
> Then let's move to get people to follow it.
>
> > 2/ It basically serves as free advertising for proprietary LLM companies.
>
> Who cares, make up a name, all I want is the "signal" that someone is
> using a LLM so that I can review it as-such. And if I think someone is
> not reporting that, I can ask for them to properly attribute it and if
> they lie, well, that's on them.
>
> > 3/ It's not clear why we want to collect this info in the first place.
>
> We want to know if a LLM is being used.
>
> > Given that the data this provides is flawed at best and is being
> > collected for a purpose that isn't clear, let's just kill the
> > requirement for these tags from the kernel at large.
>
> No, please do not do this. It's useful already for many patches in my
> subsystems, and is only going to be used more in the future.
>
> thanks,
>
> greg k-h
Entirely my view and experience. The tags are proactively useful, even if flawed
and (possibly very) incomplete.
I am totally fine with getting rid of the model however, and I do think it'd be
useful to add a small paragraph suggesting that people add a comment indicating
_how much_ of the patch was LLM-generated, even if it's vague and fuzzy.
Some information > no information.
Thanks, Lorenzo
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 15:07 ` Greg KH
2026-07-02 15:13 ` Jonathan Corbet
2026-07-02 15:15 ` Lorenzo Stoakes
@ 2026-07-02 15:33 ` Jori Koolstra
2026-07-02 15:37 ` Lorenzo Stoakes
2026-07-02 15:36 ` Laurent Pinchart
2026-07-02 15:57 ` Jeff Layton
4 siblings, 1 reply; 43+ messages in thread
From: Jori Koolstra @ 2026-07-02 15:33 UTC (permalink / raw)
To: Greg KH, Jeff Layton
Cc: Linus Torvalds, Jonathan Corbet, Justin Stitt, Lorenzo Stoakes,
Laurent Pinchart, Carlos Maiolino, Jakub Kicinski,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
> Op 02-07-2026 17:07 CEST schreef Greg KH <gregkh@linuxfoundation.org>:
>
>
> On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > We've had this requirement in place in the Documentation for several
> > months, but it's becoming clear that the signal to noise ratio from this
> > is quite low.
> >
> > 1/ It's not universally followed. While many people do try to attribute
> > the LLMs in good faith, not everyone does for various reasons.
>
> Then let's move to get people to follow it.
>
> > 2/ It basically serves as free advertising for proprietary LLM companies.
>
> Who cares, make up a name, all I want is the "signal" that someone is
> using a LLM so that I can review it as-such. And if I think someone is
> not reporting that, I can ask for them to properly attribute it and if
> they lie, well, that's on them.
>
> > 3/ It's not clear why we want to collect this info in the first place.
>
> We want to know if a LLM is being used.
>
> > Given that the data this provides is flawed at best and is being
> > collected for a purpose that isn't clear, let's just kill the
> > requirement for these tags from the kernel at large.
>
> No, please do not do this. It's useful already for many patches in my
> subsystems, and is only going to be used more in the future.
>
> thanks,
>
> greg k-h
Why not:
Keep the tag like David suggested as:
Assisted-by: LLM # automated removal of useless blabla
I am indifferent to whether this should be a tag or just below the --- .
And add something like the systemd guidelines that Christian linked to to the
AI Coding Assistants doc page. This provides much more useful guidelines than
what is currently there. I triggered this whole discussion by reading the page
and adding the model to some clean-up commits, so some people do read it...
Best,
Jori.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 15:33 ` Jori Koolstra
@ 2026-07-02 15:37 ` Lorenzo Stoakes
0 siblings, 0 replies; 43+ messages in thread
From: Lorenzo Stoakes @ 2026-07-02 15:37 UTC (permalink / raw)
To: Jori Koolstra
Cc: Greg KH, Jeff Layton, Linus Torvalds, Jonathan Corbet,
Justin Stitt, Laurent Pinchart, Carlos Maiolino, Jakub Kicinski,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Thu, Jul 02, 2026 at 05:33:12PM +0200, Jori Koolstra wrote:
>
> > Op 02-07-2026 17:07 CEST schreef Greg KH <gregkh@linuxfoundation.org>:
> >
> >
> > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > We've had this requirement in place in the Documentation for several
> > > months, but it's becoming clear that the signal to noise ratio from this
> > > is quite low.
> > >
> > > 1/ It's not universally followed. While many people do try to attribute
> > > the LLMs in good faith, not everyone does for various reasons.
> >
> > Then let's move to get people to follow it.
> >
> > > 2/ It basically serves as free advertising for proprietary LLM companies.
> >
> > Who cares, make up a name, all I want is the "signal" that someone is
> > using a LLM so that I can review it as-such. And if I think someone is
> > not reporting that, I can ask for them to properly attribute it and if
> > they lie, well, that's on them.
> >
> > > 3/ It's not clear why we want to collect this info in the first place.
> >
> > We want to know if a LLM is being used.
> >
> > > Given that the data this provides is flawed at best and is being
> > > collected for a purpose that isn't clear, let's just kill the
> > > requirement for these tags from the kernel at large.
> >
> > No, please do not do this. It's useful already for many patches in my
> > subsystems, and is only going to be used more in the future.
> >
> > thanks,
> >
> > greg k-h
>
> Why not:
>
> Keep the tag like David suggested as:
>
> Assisted-by: LLM # automated removal of useless blabla
>
> I am indifferent to whether this should be a tag or just below the --- .
>
> And add something like the systemd guidelines that Christian linked to to the
> AI Coding Assistants doc page. This provides much more useful guidelines than
> what is currently there. I triggered this whole discussion by reading the page
> and adding the model to some clean-up commits, so some people do read it...
Yup am fine with all that!
>
> Best,
> Jori.
Thanks, Lorenzo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 15:07 ` Greg KH
` (2 preceding siblings ...)
2026-07-02 15:33 ` Jori Koolstra
@ 2026-07-02 15:36 ` Laurent Pinchart
2026-07-02 15:57 ` Jeff Layton
4 siblings, 0 replies; 43+ messages in thread
From: Laurent Pinchart @ 2026-07-02 15:36 UTC (permalink / raw)
To: Greg KH
Cc: Jeff Layton, Linus Torvalds, Jonathan Corbet, Justin Stitt,
Lorenzo Stoakes, Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Thu, Jul 02, 2026 at 05:07:03PM +0200, Greg KH wrote:
> On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > We've had this requirement in place in the Documentation for several
> > months, but it's becoming clear that the signal to noise ratio from this
> > is quite low.
> >
> > 1/ It's not universally followed. While many people do try to attribute
> > the LLMs in good faith, not everyone does for various reasons.
>
> Then let's move to get people to follow it.
Has there been any discussion regarding *how* to do so ? Jon mentioned
that in many cases the failure to disclose is simply due to ignorance.
That could be addressed by more advertising (not entirely sure where
though, documentation isn't always read), or restructuring of
coding-assistants.rst (as far as I understand, the file is supposed to
be consumed by agents, so it should be reasonable to expect the LLM
output to contain a tag).
There are also cases where submitters refuse to comply with the rules
(as in [1] apparently). For those cases, a clear message that
maintainers will be fully supported by the community when they push back
could help.
[1] https://lore.kernel.org/linux-mm/20260527110147.17815-1-tao.wangtao@honor.com/
> > 2/ It basically serves as free advertising for proprietary LLM companies.
>
> Who cares, make up a name, all I want is the "signal" that someone is
> using a LLM so that I can review it as-such. And if I think someone is
> not reporting that, I can ask for them to properly attribute it and if
> they lie, well, that's on them.
>
> > 3/ It's not clear why we want to collect this info in the first place.
>
> We want to know if a LLM is being used.
>
> > Given that the data this provides is flawed at best and is being
> > collected for a purpose that isn't clear, let's just kill the
> > requirement for these tags from the kernel at large.
>
> No, please do not do this. It's useful already for many patches in my
> subsystems, and is only going to be used more in the future.
>
> thanks,
>
> greg k-h
>
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 15:07 ` Greg KH
` (3 preceding siblings ...)
2026-07-02 15:36 ` Laurent Pinchart
@ 2026-07-02 15:57 ` Jeff Layton
2026-07-02 16:13 ` Laurent Pinchart
4 siblings, 1 reply; 43+ messages in thread
From: Jeff Layton @ 2026-07-02 15:57 UTC (permalink / raw)
To: Greg KH
Cc: Linus Torvalds, Jonathan Corbet, Justin Stitt, Lorenzo Stoakes,
Laurent Pinchart, Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Thu, 2026-07-02 at 17:07 +0200, Greg KH wrote:
> On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > We've had this requirement in place in the Documentation for several
> > months, but it's becoming clear that the signal to noise ratio from this
> > is quite low.
> >
> > 1/ It's not universally followed. While many people do try to attribute
> > the LLMs in good faith, not everyone does for various reasons.
>
> Then let's move to get people to follow it.
>
> > 2/ It basically serves as free advertising for proprietary LLM companies.
>
> Who cares, make up a name, all I want is the "signal" that someone is
> using a LLM so that I can review it as-such. And if I think someone is
> not reporting that, I can ask for them to properly attribute it and if
> they lie, well, that's on them.
>
> > 3/ It's not clear why we want to collect this info in the first place.
>
> We want to know if a LLM is being used.
>
But why? What do you intend to do with this information?
Do you mean to use it as an indicator that the patch should receive
"extra" review (or maybe that it should be ignored)? Do you mean to use
it to generate some sort of statistics at a later time?
If we want to collect some sort of structured data like this, it would
be good to have some idea of how it will be used. That might inform the
format and content of what we're collecting.
> > Given that the data this provides is flawed at best and is being
> > collected for a purpose that isn't clear, let's just kill the
> > requirement for these tags from the kernel at large.
>
> No, please do not do this. It's useful already for many patches in my
> subsystems, and is only going to be used more in the future.
>
I should have sent this as an RFC patch, but hopefully everyone is
treating that way anyway. To be clear, I don't have a strong preference
on whether we keep Assisted-by: or not, but I'd like to better
understand the intended uses of it if we do intend to keep it.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply [flat|nested] 43+ messages in thread* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 15:57 ` Jeff Layton
@ 2026-07-02 16:13 ` Laurent Pinchart
2026-07-02 16:19 ` Greg KH
0 siblings, 1 reply; 43+ messages in thread
From: Laurent Pinchart @ 2026-07-02 16:13 UTC (permalink / raw)
To: Jeff Layton
Cc: Greg KH, Linus Torvalds, Jonathan Corbet, Justin Stitt,
Lorenzo Stoakes, Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Thu, Jul 02, 2026 at 11:57:46AM -0400, Jeff Layton wrote:
> On Thu, 2026-07-02 at 17:07 +0200, Greg KH wrote:
> > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > We've had this requirement in place in the Documentation for several
> > > months, but it's becoming clear that the signal to noise ratio from this
> > > is quite low.
> > >
> > > 1/ It's not universally followed. While many people do try to attribute
> > > the LLMs in good faith, not everyone does for various reasons.
> >
> > Then let's move to get people to follow it.
> >
> > > 2/ It basically serves as free advertising for proprietary LLM companies.
> >
> > Who cares, make up a name, all I want is the "signal" that someone is
> > using a LLM so that I can review it as-such. And if I think someone is
> > not reporting that, I can ask for them to properly attribute it and if
> > they lie, well, that's on them.
> >
> > > 3/ It's not clear why we want to collect this info in the first place.
> >
> > We want to know if a LLM is being used.
>
> But why? What do you intend to do with this information?
>
> Do you mean to use it as an indicator that the patch should receive
> "extra" review (or maybe that it should be ignored)? Do you mean to use
> it to generate some sort of statistics at a later time?
I use the information to decide how to review the patch, and what level
of priority to give it. For that usage I don't need a tag, but I need
the information in some human-readable form at patch submission time.
> If we want to collect some sort of structured data like this, it would
> be good to have some idea of how it will be used. That might inform the
> format and content of what we're collecting.
>
> > > Given that the data this provides is flawed at best and is being
> > > collected for a purpose that isn't clear, let's just kill the
> > > requirement for these tags from the kernel at large.
> >
> > No, please do not do this. It's useful already for many patches in my
> > subsystems, and is only going to be used more in the future.
>
> I should have sent this as an RFC patch, but hopefully everyone is
> treating that way anyway. To be clear, I don't have a strong preference
> on whether we keep Assisted-by: or not, but I'd like to better
> understand the intended uses of it if we do intend to keep it.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 16:13 ` Laurent Pinchart
@ 2026-07-02 16:19 ` Greg KH
2026-07-02 16:32 ` Laurent Pinchart
2026-07-02 16:48 ` Jeff Layton
0 siblings, 2 replies; 43+ messages in thread
From: Greg KH @ 2026-07-02 16:19 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Jeff Layton, Linus Torvalds, Jonathan Corbet, Justin Stitt,
Lorenzo Stoakes, Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Thu, Jul 02, 2026 at 07:13:30PM +0300, Laurent Pinchart wrote:
> On Thu, Jul 02, 2026 at 11:57:46AM -0400, Jeff Layton wrote:
> > On Thu, 2026-07-02 at 17:07 +0200, Greg KH wrote:
> > > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > > We've had this requirement in place in the Documentation for several
> > > > months, but it's becoming clear that the signal to noise ratio from this
> > > > is quite low.
> > > >
> > > > 1/ It's not universally followed. While many people do try to attribute
> > > > the LLMs in good faith, not everyone does for various reasons.
> > >
> > > Then let's move to get people to follow it.
> > >
> > > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > >
> > > Who cares, make up a name, all I want is the "signal" that someone is
> > > using a LLM so that I can review it as-such. And if I think someone is
> > > not reporting that, I can ask for them to properly attribute it and if
> > > they lie, well, that's on them.
> > >
> > > > 3/ It's not clear why we want to collect this info in the first place.
> > >
> > > We want to know if a LLM is being used.
> >
> > But why? What do you intend to do with this information?
> >
> > Do you mean to use it as an indicator that the patch should receive
> > "extra" review (or maybe that it should be ignored)? Do you mean to use
> > it to generate some sort of statistics at a later time?
>
> I use the information to decide how to review the patch, and what level
> of priority to give it. For that usage I don't need a tag, but I need
> the information in some human-readable form at patch submission time.
Same here. I don't care about stats, I care about "how do I review this
patch" and this gives me that signal that I need if faced with a
llm-helped patch.
So it needs to stay please.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 16:19 ` Greg KH
@ 2026-07-02 16:32 ` Laurent Pinchart
2026-07-03 6:37 ` Greg KH
2026-07-02 16:48 ` Jeff Layton
1 sibling, 1 reply; 43+ messages in thread
From: Laurent Pinchart @ 2026-07-02 16:32 UTC (permalink / raw)
To: Greg KH
Cc: Jeff Layton, Linus Torvalds, Jonathan Corbet, Justin Stitt,
Lorenzo Stoakes, Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Thu, Jul 02, 2026 at 06:19:15PM +0200, Greg KH wrote:
> On Thu, Jul 02, 2026 at 07:13:30PM +0300, Laurent Pinchart wrote:
> > On Thu, Jul 02, 2026 at 11:57:46AM -0400, Jeff Layton wrote:
> > > On Thu, 2026-07-02 at 17:07 +0200, Greg KH wrote:
> > > > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > > > We've had this requirement in place in the Documentation for several
> > > > > months, but it's becoming clear that the signal to noise ratio from this
> > > > > is quite low.
> > > > >
> > > > > 1/ It's not universally followed. While many people do try to attribute
> > > > > the LLMs in good faith, not everyone does for various reasons.
> > > >
> > > > Then let's move to get people to follow it.
> > > >
> > > > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > > >
> > > > Who cares, make up a name, all I want is the "signal" that someone is
> > > > using a LLM so that I can review it as-such. And if I think someone is
> > > > not reporting that, I can ask for them to properly attribute it and if
> > > > they lie, well, that's on them.
> > > >
> > > > > 3/ It's not clear why we want to collect this info in the first place.
> > > >
> > > > We want to know if a LLM is being used.
> > >
> > > But why? What do you intend to do with this information?
> > >
> > > Do you mean to use it as an indicator that the patch should receive
> > > "extra" review (or maybe that it should be ignored)? Do you mean to use
> > > it to generate some sort of statistics at a later time?
> >
> > I use the information to decide how to review the patch, and what level
> > of priority to give it. For that usage I don't need a tag, but I need
> > the information in some human-readable form at patch submission time.
>
> Same here. I don't care about stats, I care about "how do I review this
> patch" and this gives me that signal that I need if faced with a
> llm-helped patch.
>
> So it needs to stay please.
There's the free advertising issue we still need to address. Would the
proposed "Assisted-by: LLM" tag to replace product names be an
acceptable option for you ?
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 16:32 ` Laurent Pinchart
@ 2026-07-03 6:37 ` Greg KH
2026-07-03 7:23 ` David Hildenbrand (Arm)
0 siblings, 1 reply; 43+ messages in thread
From: Greg KH @ 2026-07-03 6:37 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Jeff Layton, Linus Torvalds, Jonathan Corbet, Justin Stitt,
Lorenzo Stoakes, Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Thu, Jul 02, 2026 at 07:32:15PM +0300, Laurent Pinchart wrote:
> On Thu, Jul 02, 2026 at 06:19:15PM +0200, Greg KH wrote:
> > On Thu, Jul 02, 2026 at 07:13:30PM +0300, Laurent Pinchart wrote:
> > > On Thu, Jul 02, 2026 at 11:57:46AM -0400, Jeff Layton wrote:
> > > > On Thu, 2026-07-02 at 17:07 +0200, Greg KH wrote:
> > > > > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > > > > We've had this requirement in place in the Documentation for several
> > > > > > months, but it's becoming clear that the signal to noise ratio from this
> > > > > > is quite low.
> > > > > >
> > > > > > 1/ It's not universally followed. While many people do try to attribute
> > > > > > the LLMs in good faith, not everyone does for various reasons.
> > > > >
> > > > > Then let's move to get people to follow it.
> > > > >
> > > > > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > > > >
> > > > > Who cares, make up a name, all I want is the "signal" that someone is
> > > > > using a LLM so that I can review it as-such. And if I think someone is
> > > > > not reporting that, I can ask for them to properly attribute it and if
> > > > > they lie, well, that's on them.
> > > > >
> > > > > > 3/ It's not clear why we want to collect this info in the first place.
> > > > >
> > > > > We want to know if a LLM is being used.
> > > >
> > > > But why? What do you intend to do with this information?
> > > >
> > > > Do you mean to use it as an indicator that the patch should receive
> > > > "extra" review (or maybe that it should be ignored)? Do you mean to use
> > > > it to generate some sort of statistics at a later time?
> > >
> > > I use the information to decide how to review the patch, and what level
> > > of priority to give it. For that usage I don't need a tag, but I need
> > > the information in some human-readable form at patch submission time.
> >
> > Same here. I don't care about stats, I care about "how do I review this
> > patch" and this gives me that signal that I need if faced with a
> > llm-helped patch.
> >
> > So it needs to stay please.
>
> There's the free advertising issue we still need to address. Would the
> proposed "Assisted-by: LLM" tag to replace product names be an
> acceptable option for you ?
I really don't care what the tag says, I just want to see the tag stay
to show that this needs to be evaluated differently than if it was made
only by a person. Some people might want to "show off" their model
names, while other companies I know refuse to allow the name to be
shown, so it really doesn't hurt anyone to keep it as-is.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 6:37 ` Greg KH
@ 2026-07-03 7:23 ` David Hildenbrand (Arm)
2026-07-03 7:30 ` Greg KH
0 siblings, 1 reply; 43+ messages in thread
From: David Hildenbrand (Arm) @ 2026-07-03 7:23 UTC (permalink / raw)
To: Greg KH, Laurent Pinchart, Linus Torvalds
Cc: Jeff Layton, Jonathan Corbet, Justin Stitt, Lorenzo Stoakes,
Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
Vlastimil Babka, Christian Brauner (Amutable), workflows,
linux-doc, linux-kernel, linux-fsdevel
On 7/3/26 08:37, Greg KH wrote:
> On Thu, Jul 02, 2026 at 07:32:15PM +0300, Laurent Pinchart wrote:
>> On Thu, Jul 02, 2026 at 06:19:15PM +0200, Greg KH wrote:
>>>
>>> Same here. I don't care about stats, I care about "how do I review this
>>> patch" and this gives me that signal that I need if faced with a
>>> llm-helped patch.
>>>
>>> So it needs to stay please.
>>
>> There's the free advertising issue we still need to address. Would the
>> proposed "Assisted-by: LLM" tag to replace product names be an
>> acceptable option for you ?
>
> I really don't care what the tag says,
Well, while you don't care, the current policy implies that:
"
Assisted-by: AGENT_NAME:MODEL_VERSION
...
``MODEL_VERSION`` is the specific model version used
"
So clarifying there that a "Assisted-by: LLM" is also good enough would make
sense if we agree on that.
I'll also note, that the "*should* include an Assisted-by tag" is pretty weak,
as someone who worked on specs before.
My kids should clean up their room; doesn't work.
Really, if we want this to be useful in practice I only see the following way:
1) Document that it's a *must*, an document which scenarios we care about.
2) Encourage people to specify *how* AI was used.
Assisted-by: LLM # improve the patch description
Now, it will be hard for all susbsytems to agree on that, so I would hope that
Linus would just tell us what we should do :)
--
Cheers,
David
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 7:23 ` David Hildenbrand (Arm)
@ 2026-07-03 7:30 ` Greg KH
2026-07-03 7:33 ` David Hildenbrand (Arm)
2026-07-03 11:42 ` Theodore Tso
0 siblings, 2 replies; 43+ messages in thread
From: Greg KH @ 2026-07-03 7:30 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Laurent Pinchart, Linus Torvalds, Jeff Layton, Jonathan Corbet,
Justin Stitt, Lorenzo Stoakes, Carlos Maiolino, Jakub Kicinski,
Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Fri, Jul 03, 2026 at 09:23:11AM +0200, David Hildenbrand (Arm) wrote:
> On 7/3/26 08:37, Greg KH wrote:
> > On Thu, Jul 02, 2026 at 07:32:15PM +0300, Laurent Pinchart wrote:
> >> On Thu, Jul 02, 2026 at 06:19:15PM +0200, Greg KH wrote:
> >>>
> >>> Same here. I don't care about stats, I care about "how do I review this
> >>> patch" and this gives me that signal that I need if faced with a
> >>> llm-helped patch.
> >>>
> >>> So it needs to stay please.
> >>
> >> There's the free advertising issue we still need to address. Would the
> >> proposed "Assisted-by: LLM" tag to replace product names be an
> >> acceptable option for you ?
> >
> > I really don't care what the tag says,
>
> Well, while you don't care, the current policy implies that:
>
> "
> Assisted-by: AGENT_NAME:MODEL_VERSION
> ...
> ``MODEL_VERSION`` is the specific model version used
> "
>
> So clarifying there that a "Assisted-by: LLM" is also good enough would make
> sense if we agree on that.
If we all agree on that, I'm saying that _I_ don't care, but others
might.
For me, the info after "Assisted-by:" doesn't matter, it's the first
part.
> I'll also note, that the "*should* include an Assisted-by tag" is pretty weak,
> as someone who worked on specs before.
>
> My kids should clean up their room; doesn't work.
But, if you notice that your kids didn't clean up their room, and you
had told them to, you can then talk to them about doing it properly
based on what they are supposed to be doing.
That's the point here.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 7:30 ` Greg KH
@ 2026-07-03 7:33 ` David Hildenbrand (Arm)
2026-07-03 11:42 ` Theodore Tso
1 sibling, 0 replies; 43+ messages in thread
From: David Hildenbrand (Arm) @ 2026-07-03 7:33 UTC (permalink / raw)
To: Greg KH
Cc: Laurent Pinchart, Linus Torvalds, Jeff Layton, Jonathan Corbet,
Justin Stitt, Lorenzo Stoakes, Carlos Maiolino, Jakub Kicinski,
Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
>> I'll also note, that the "*should* include an Assisted-by tag" is pretty weak,
>> as someone who worked on specs before.
>>
>> My kids should clean up their room; doesn't work.
>
> But, if you notice that your kids didn't clean up their room, and you
> had told them to, you can then talk to them about doing it properly
> based on what they are supposed to be doing.
>
> That's the point here.
Well, they are smart. They will tell me that it was not a strict requirement.
So I'll have to rephrase it as "STOP ARGUING, CLEAN UP YOUR ROOM!!!" ;)
--
Cheers,
David
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 7:30 ` Greg KH
2026-07-03 7:33 ` David Hildenbrand (Arm)
@ 2026-07-03 11:42 ` Theodore Tso
2026-07-03 11:53 ` Laurent Pinchart
2026-07-03 12:04 ` Jori Koolstra
1 sibling, 2 replies; 43+ messages in thread
From: Theodore Tso @ 2026-07-03 11:42 UTC (permalink / raw)
To: Greg KH
Cc: David Hildenbrand (Arm), Laurent Pinchart, Linus Torvalds,
Jeff Layton, Jonathan Corbet, Justin Stitt, Lorenzo Stoakes,
Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
Vlastimil Babka, Christian Brauner (Amutable), workflows,
linux-doc, linux-kernel, linux-fsdevel
On Fri, Jul 03, 2026 at 09:30:28AM -0500, Greg KH wrote:
> > So clarifying there that a "Assisted-by: LLM" is also good enough would make
> > sense if we agree on that.
>
> If we all agree on that, I'm saying that _I_ don't care, but others
> might.
I agree that requiring the model name is not a good idea, because some
developers might be using unreleased products where the name itself
might not be public. So allowing the version number of the LLM to be
elided would be a good change.
I'll also note that it's starting to be the case where tool is
actually quite relevant. So it's not just about the LLM Model, but
whether you're using Codex, Claude Code, OpenCode, or Shahiko. You
can use the tool or the harness with different models.
So whether the tag is:
Assisted-By: OpenCode:Gemini 3.5 Pro
Assisted-By: Claude Code
Assisted-By: LLM
I'd be fine with reviewing patches with any of the above. However, to
me that's actually not the most interesting part. See below....
> For me, the info after "Assisted-by:" doesn't matter, it's the first
> part.
For me, what I care most about is *how* the LLM was used. For
example, if someone just used the output of Sashiko to fix a problem
in their commit, that's one kind of "Assisted-by". If Sahsiko
identifies a pre-existing bug, and the developer addes a patch to the
patch series, or creates a new patch series, that's a different kind
of "Assisted-by". A third kind of "Assisted-by" might include asking
the LLM to create a Coccinelle semantic patches (because I'm not smart
enough to create semantic patches).
And of course, all of this is quite different from the stereotypical
"vibe coding" where the LLM generates thousands of lines of code which
the human doesn't understand before sending the pull request. :-)
So for me, adding something after a #-sign comment explaning how the
LLM was used would be very useful.
> > My kids should clean up their room; doesn't work.
>
> But, if you notice that your kids didn't clean up their room, and you
> had told them to, you can then talk to them about doing it properly
> based on what they are supposed to be doing.
Another metaphor might be that people shouldn't try to evade paying
their taxes; merely passing a law saying they have to file correct tax
returns doesn't guarantee this. But it was specifically the law
against tax evasion is how US Law Enforcement arrested the Chicago mob
boss Al Capone.
Just because some people might lie doesn't mean that we shouldn't
bother to ask everyone to fill out tax returns.
Cheers,
- Ted
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 11:42 ` Theodore Tso
@ 2026-07-03 11:53 ` Laurent Pinchart
2026-07-03 12:04 ` Jori Koolstra
1 sibling, 0 replies; 43+ messages in thread
From: Laurent Pinchart @ 2026-07-03 11:53 UTC (permalink / raw)
To: Theodore Tso
Cc: Greg KH, David Hildenbrand (Arm), Linus Torvalds, Jeff Layton,
Jonathan Corbet, Justin Stitt, Lorenzo Stoakes, Carlos Maiolino,
Jakub Kicinski, Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Fri, Jul 03, 2026 at 07:42:35AM -0400, Theodore Tso wrote:
> On Fri, Jul 03, 2026 at 09:30:28AM -0500, Greg KH wrote:
> > > So clarifying there that a "Assisted-by: LLM" is also good enough would make
> > > sense if we agree on that.
> >
> > If we all agree on that, I'm saying that _I_ don't care, but others
> > might.
>
> I agree that requiring the model name is not a good idea, because some
> developers might be using unreleased products where the name itself
> might not be public. So allowing the version number of the LLM to be
> elided would be a good change.
>
> I'll also note that it's starting to be the case where tool is
> actually quite relevant. So it's not just about the LLM Model, but
> whether you're using Codex, Claude Code, OpenCode, or Shahiko. You
> can use the tool or the harness with different models.
>
> So whether the tag is:
>
> Assisted-By: OpenCode:Gemini 3.5 Pro
> Assisted-By: Claude Code
> Assisted-By: LLM
>
> I'd be fine with reviewing patches with any of the above. However, to
> me that's actually not the most interesting part. See below....
>
> > For me, the info after "Assisted-by:" doesn't matter, it's the first
> > part.
>
> For me, what I care most about is *how* the LLM was used. For
> example, if someone just used the output of Sashiko to fix a problem
> in their commit, that's one kind of "Assisted-by". If Sahsiko
> identifies a pre-existing bug, and the developer addes a patch to the
> patch series, or creates a new patch series, that's a different kind
> of "Assisted-by". A third kind of "Assisted-by" might include asking
> the LLM to create a Coccinelle semantic patches (because I'm not smart
> enough to create semantic patches).
>
> And of course, all of this is quite different from the stereotypical
> "vibe coding" where the LLM generates thousands of lines of code which
> the human doesn't understand before sending the pull request. :-)
>
> So for me, adding something after a #-sign comment explaning how the
> LLM was used would be very useful.
>
> > > My kids should clean up their room; doesn't work.
> >
> > But, if you notice that your kids didn't clean up their room, and you
> > had told them to, you can then talk to them about doing it properly
> > based on what they are supposed to be doing.
>
> Another metaphor might be that people shouldn't try to evade paying
> their taxes; merely passing a law saying they have to file correct tax
> returns doesn't guarantee this. But it was specifically the law
> against tax evasion is how US Law Enforcement arrested the Chicago mob
> boss Al Capone.
>
> Just because some people might lie doesn't mean that we shouldn't
> bother to ask everyone to fill out tax returns.
I think we're digressing here. The original point, if I understood it
carefully, is that "must" would convey a requirement better than
"should", and I agree with that.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 11:42 ` Theodore Tso
2026-07-03 11:53 ` Laurent Pinchart
@ 2026-07-03 12:04 ` Jori Koolstra
1 sibling, 0 replies; 43+ messages in thread
From: Jori Koolstra @ 2026-07-03 12:04 UTC (permalink / raw)
To: Theodore Tso, Greg KH
Cc: David Hildenbrand (Arm), Laurent Pinchart, Linus Torvalds,
Jeff Layton, Jonathan Corbet, Justin Stitt, Lorenzo Stoakes,
Carlos Maiolino, Jakub Kicinski, Krzysztof Kozlowski,
Brian Foster, Christoph Hellwig, David Disseldorp, Mark Brown,
Jani Nikula, Jens Axboe, Vlastimil Babka,
Christian Brauner (Amutable), workflows, linux-doc, linux-kernel,
linux-fsdevel
> Op 03-07-2026 13:42 CEST schreef Theodore Tso <tytso@mit.edu>:
>
> Another metaphor might be that people shouldn't try to evade paying
> their taxes; merely passing a law saying they have to file correct tax
> returns doesn't guarantee this. But it was specifically the law
> against tax evasion is how US Law Enforcement arrested the Chicago mob
> boss Al Capone.
>
> Just because some people might lie doesn't mean that we shouldn't
> bother to ask everyone to fill out tax returns.
>
> Cheers,
>
> - Ted
I think the point that some people who are more negative on keeping the tag
in were trying to make is not that we expect everyone to follow the rules, but
that having rules with no consequences are bad rules in general. And this is
illustrated by your example.
But I see there is quite a bit of consensus on the general needs:
- it's more relevant to know how an LLM was used than that it was used (and the
tag is just a quick indication of this)
- advertising for particular corporations does not really serve any purpose to
the community, so just say "LLM"
- the tags may be used to prevent arguing
- the requirement to be open about LLM use (whether by tags or whatever) makes
it easier for maintainers (if they feel the need) to de-prioritize patches
by someone unwilling to abide by these rules whenever the maintainer perceives
or suspects prior undeclared LLM use. This prevents an asymmetrical situation
of LLM slop being produced much faster that what can be reviewed.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 16:19 ` Greg KH
2026-07-02 16:32 ` Laurent Pinchart
@ 2026-07-02 16:48 ` Jeff Layton
2026-07-02 16:50 ` Lorenzo Stoakes
1 sibling, 1 reply; 43+ messages in thread
From: Jeff Layton @ 2026-07-02 16:48 UTC (permalink / raw)
To: Greg KH, Laurent Pinchart
Cc: Linus Torvalds, Jonathan Corbet, Justin Stitt, Lorenzo Stoakes,
Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Thu, 2026-07-02 at 18:19 +0200, Greg KH wrote:
> On Thu, Jul 02, 2026 at 07:13:30PM +0300, Laurent Pinchart wrote:
> > On Thu, Jul 02, 2026 at 11:57:46AM -0400, Jeff Layton wrote:
> > > On Thu, 2026-07-02 at 17:07 +0200, Greg KH wrote:
> > > > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > > > We've had this requirement in place in the Documentation for several
> > > > > months, but it's becoming clear that the signal to noise ratio from this
> > > > > is quite low.
> > > > >
> > > > > 1/ It's not universally followed. While many people do try to attribute
> > > > > the LLMs in good faith, not everyone does for various reasons.
> > > >
> > > > Then let's move to get people to follow it.
> > > >
> > > > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > > >
> > > > Who cares, make up a name, all I want is the "signal" that someone is
> > > > using a LLM so that I can review it as-such. And if I think someone is
> > > > not reporting that, I can ask for them to properly attribute it and if
> > > > they lie, well, that's on them.
> > > >
> > > > > 3/ It's not clear why we want to collect this info in the first place.
> > > >
> > > > We want to know if a LLM is being used.
> > >
> > > But why? What do you intend to do with this information?
> > >
> > > Do you mean to use it as an indicator that the patch should receive
> > > "extra" review (or maybe that it should be ignored)? Do you mean to use
> > > it to generate some sort of statistics at a later time?
> >
> > I use the information to decide how to review the patch, and what level
> > of priority to give it. For that usage I don't need a tag, but I need
> > the information in some human-readable form at patch submission time.
>
> Same here. I don't care about stats, I care about "how do I review this
> patch" and this gives me that signal that I need if faced with a
> llm-helped patch.
>
>
Do we need a tag for this though?
This seems like the kind of information that we would always require in
the cover letter of a series (or the little place in an individual
patch for comments that don't get merged). That would also allow you to
convey a lot more nuance about how it was used.
ISTM asking people to disclose LLM usage in a cover letter would give
everyone what they want: Information about whether and possibly how an
LLM was used, and it also wouldn't clutter up the changelogs with these
tags.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 16:48 ` Jeff Layton
@ 2026-07-02 16:50 ` Lorenzo Stoakes
2026-07-02 21:17 ` Boris Burkov
2026-07-02 23:05 ` SJ Park
0 siblings, 2 replies; 43+ messages in thread
From: Lorenzo Stoakes @ 2026-07-02 16:50 UTC (permalink / raw)
To: Jeff Layton
Cc: Greg KH, Laurent Pinchart, Linus Torvalds, Jonathan Corbet,
Justin Stitt, Carlos Maiolino, Jakub Kicinski, Jori Koolstra,
Krzysztof Kozlowski, Brian Foster, Christoph Hellwig,
David Disseldorp, Mark Brown, Jani Nikula, Jens Axboe,
David Hildenbrand, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Thu, Jul 02, 2026 at 12:48:22PM -0400, Jeff Layton wrote:
> On Thu, 2026-07-02 at 18:19 +0200, Greg KH wrote:
> > On Thu, Jul 02, 2026 at 07:13:30PM +0300, Laurent Pinchart wrote:
> > > On Thu, Jul 02, 2026 at 11:57:46AM -0400, Jeff Layton wrote:
> > > > On Thu, 2026-07-02 at 17:07 +0200, Greg KH wrote:
> > > > > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > > > > We've had this requirement in place in the Documentation for several
> > > > > > months, but it's becoming clear that the signal to noise ratio from this
> > > > > > is quite low.
> > > > > >
> > > > > > 1/ It's not universally followed. While many people do try to attribute
> > > > > > the LLMs in good faith, not everyone does for various reasons.
> > > > >
> > > > > Then let's move to get people to follow it.
> > > > >
> > > > > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > > > >
> > > > > Who cares, make up a name, all I want is the "signal" that someone is
> > > > > using a LLM so that I can review it as-such. And if I think someone is
> > > > > not reporting that, I can ask for them to properly attribute it and if
> > > > > they lie, well, that's on them.
> > > > >
> > > > > > 3/ It's not clear why we want to collect this info in the first place.
> > > > >
> > > > > We want to know if a LLM is being used.
> > > >
> > > > But why? What do you intend to do with this information?
> > > >
> > > > Do you mean to use it as an indicator that the patch should receive
> > > > "extra" review (or maybe that it should be ignored)? Do you mean to use
> > > > it to generate some sort of statistics at a later time?
> > >
> > > I use the information to decide how to review the patch, and what level
> > > of priority to give it. For that usage I don't need a tag, but I need
> > > the information in some human-readable form at patch submission time.
> >
> > Same here. I don't care about stats, I care about "how do I review this
> > patch" and this gives me that signal that I need if faced with a
> > llm-helped patch.
> >
> >
>
> Do we need a tag for this though?
>
> This seems like the kind of information that we would always require in
> the cover letter of a series (or the little place in an individual
> patch for comments that don't get merged). That would also allow you to
> convey a lot more nuance about how it was used.
>
> ISTM asking people to disclose LLM usage in a cover letter would give
> everyone what they want: Information about whether and possibly how an
> LLM was used, and it also wouldn't clutter up the changelogs with these
> tags.
It's much much clearer and easier to just have a standardised tag for that.
You can see that (and grep for that) immediately, vague paragraphs not so much.
> --
> Jeff Layton <jlayton@kernel.org>
Thanks, Lroenzo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 16:50 ` Lorenzo Stoakes
@ 2026-07-02 21:17 ` Boris Burkov
2026-07-02 23:17 ` SJ Park
2026-07-03 7:05 ` David Hildenbrand (Arm)
2026-07-02 23:05 ` SJ Park
1 sibling, 2 replies; 43+ messages in thread
From: Boris Burkov @ 2026-07-02 21:17 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Jeff Layton, Greg KH, Laurent Pinchart, Linus Torvalds,
Jonathan Corbet, Justin Stitt, Carlos Maiolino, Jakub Kicinski,
Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, David Hildenbrand, Vlastimil Babka,
Christian Brauner (Amutable), workflows, linux-doc, linux-kernel,
linux-fsdevel
On Thu, Jul 02, 2026 at 05:50:15PM +0100, Lorenzo Stoakes wrote:
> On Thu, Jul 02, 2026 at 12:48:22PM -0400, Jeff Layton wrote:
> > On Thu, 2026-07-02 at 18:19 +0200, Greg KH wrote:
> > > On Thu, Jul 02, 2026 at 07:13:30PM +0300, Laurent Pinchart wrote:
> > > > On Thu, Jul 02, 2026 at 11:57:46AM -0400, Jeff Layton wrote:
> > > > > On Thu, 2026-07-02 at 17:07 +0200, Greg KH wrote:
> > > > > > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > > > > > We've had this requirement in place in the Documentation for several
> > > > > > > months, but it's becoming clear that the signal to noise ratio from this
> > > > > > > is quite low.
> > > > > > >
> > > > > > > 1/ It's not universally followed. While many people do try to attribute
> > > > > > > the LLMs in good faith, not everyone does for various reasons.
> > > > > >
> > > > > > Then let's move to get people to follow it.
> > > > > >
> > > > > > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > > > > >
> > > > > > Who cares, make up a name, all I want is the "signal" that someone is
> > > > > > using a LLM so that I can review it as-such. And if I think someone is
> > > > > > not reporting that, I can ask for them to properly attribute it and if
> > > > > > they lie, well, that's on them.
> > > > > >
> > > > > > > 3/ It's not clear why we want to collect this info in the first place.
> > > > > >
> > > > > > We want to know if a LLM is being used.
> > > > >
> > > > > But why? What do you intend to do with this information?
> > > > >
> > > > > Do you mean to use it as an indicator that the patch should receive
> > > > > "extra" review (or maybe that it should be ignored)? Do you mean to use
> > > > > it to generate some sort of statistics at a later time?
> > > >
> > > > I use the information to decide how to review the patch, and what level
> > > > of priority to give it. For that usage I don't need a tag, but I need
> > > > the information in some human-readable form at patch submission time.
> > >
> > > Same here. I don't care about stats, I care about "how do I review this
> > > patch" and this gives me that signal that I need if faced with a
> > > llm-helped patch.
> > >
> > >
> >
> > Do we need a tag for this though?
> >
> > This seems like the kind of information that we would always require in
> > the cover letter of a series (or the little place in an individual
> > patch for comments that don't get merged). That would also allow you to
> > convey a lot more nuance about how it was used.
> >
> > ISTM asking people to disclose LLM usage in a cover letter would give
> > everyone what they want: Information about whether and possibly how an
> > LLM was used, and it also wouldn't clutter up the changelogs with these
> > tags.
>
> It's much much clearer and easier to just have a standardised tag for that.
>
> You can see that (and grep for that) immediately, vague paragraphs not so much.
>
At the risk of being pedantic on a point where I think the document is
kind of lacking:
What level of assistance crosses the bar for an "Assisted-by: LLM" tag?
Some sample levels of assistance to illustrate the point:
1. I used an llm to one-shot vibe-code a patch
2. I used an llm to write a patch but carefully reviewed every line
3. I used an llm to explore the design space for a patch but wrote it
manually
4. I used an llm to debug or reproduce a kernel issue but then wrote the
fix manually after fully understanding the defect
5. I used an llm to review a patch I wrote
6. I used an llm to research some chunk of code while writing a patch
7. I used Google while writing a patch and learned something valuable
from the AI overview at the top
I personally would 100% use the tag for 1 or 2, and have already done
so. I have not been doing it for 3-5, as I think that will basically
make every patch llm-assisted to the point of the distinction being
meaningless. If we should be doing it for 3-5 (or some subset thereof)
then my mistake and I will certainly start doing so. I would hope most
people agree 6-7 and similar need no tag.
Similar questions abound if you use an llm to help with writing the
English text in the patch or emails.
I have a feeling that this ambiguity is part of the reason we aren't all
agreeing on the value of the tag?
Thanks,
Boris
> > --
> > Jeff Layton <jlayton@kernel.org>
>
> Thanks, Lroenzo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 21:17 ` Boris Burkov
@ 2026-07-02 23:17 ` SJ Park
2026-07-03 7:05 ` David Hildenbrand (Arm)
1 sibling, 0 replies; 43+ messages in thread
From: SJ Park @ 2026-07-02 23:17 UTC (permalink / raw)
To: Boris Burkov
Cc: SJ Park, Lorenzo Stoakes, Jeff Layton, Greg KH, Laurent Pinchart,
Linus Torvalds, Jonathan Corbet, Justin Stitt, Carlos Maiolino,
Jakub Kicinski, Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, David Hildenbrand, Vlastimil Babka,
Christian Brauner (Amutable), workflows, linux-doc, linux-kernel,
linux-fsdevel
On Thu, 2 Jul 2026 14:17:40 -0700 Boris Burkov <boris@bur.io> wrote:
> On Thu, Jul 02, 2026 at 05:50:15PM +0100, Lorenzo Stoakes wrote:
> > On Thu, Jul 02, 2026 at 12:48:22PM -0400, Jeff Layton wrote:
> > > On Thu, 2026-07-02 at 18:19 +0200, Greg KH wrote:
> > > > On Thu, Jul 02, 2026 at 07:13:30PM +0300, Laurent Pinchart wrote:
> > > > > On Thu, Jul 02, 2026 at 11:57:46AM -0400, Jeff Layton wrote:
> > > > > > On Thu, 2026-07-02 at 17:07 +0200, Greg KH wrote:
> > > > > > > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > > > > > > We've had this requirement in place in the Documentation for several
> > > > > > > > months, but it's becoming clear that the signal to noise ratio from this
> > > > > > > > is quite low.
> > > > > > > >
> > > > > > > > 1/ It's not universally followed. While many people do try to attribute
> > > > > > > > the LLMs in good faith, not everyone does for various reasons.
> > > > > > >
> > > > > > > Then let's move to get people to follow it.
> > > > > > >
> > > > > > > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > > > > > >
> > > > > > > Who cares, make up a name, all I want is the "signal" that someone is
> > > > > > > using a LLM so that I can review it as-such. And if I think someone is
> > > > > > > not reporting that, I can ask for them to properly attribute it and if
> > > > > > > they lie, well, that's on them.
> > > > > > >
> > > > > > > > 3/ It's not clear why we want to collect this info in the first place.
> > > > > > >
> > > > > > > We want to know if a LLM is being used.
> > > > > >
> > > > > > But why? What do you intend to do with this information?
> > > > > >
> > > > > > Do you mean to use it as an indicator that the patch should receive
> > > > > > "extra" review (or maybe that it should be ignored)? Do you mean to use
> > > > > > it to generate some sort of statistics at a later time?
> > > > >
> > > > > I use the information to decide how to review the patch, and what level
> > > > > of priority to give it. For that usage I don't need a tag, but I need
> > > > > the information in some human-readable form at patch submission time.
> > > >
> > > > Same here. I don't care about stats, I care about "how do I review this
> > > > patch" and this gives me that signal that I need if faced with a
> > > > llm-helped patch.
> > > >
> > > >
> > >
> > > Do we need a tag for this though?
> > >
> > > This seems like the kind of information that we would always require in
> > > the cover letter of a series (or the little place in an individual
> > > patch for comments that don't get merged). That would also allow you to
> > > convey a lot more nuance about how it was used.
> > >
> > > ISTM asking people to disclose LLM usage in a cover letter would give
> > > everyone what they want: Information about whether and possibly how an
> > > LLM was used, and it also wouldn't clutter up the changelogs with these
> > > tags.
> >
> > It's much much clearer and easier to just have a standardised tag for that.
> >
> > You can see that (and grep for that) immediately, vague paragraphs not so much.
> >
>
> At the risk of being pedantic on a point where I think the document is
> kind of lacking:
>
> What level of assistance crosses the bar for an "Assisted-by: LLM" tag?
>
> Some sample levels of assistance to illustrate the point:
>
> 1. I used an llm to one-shot vibe-code a patch
> 2. I used an llm to write a patch but carefully reviewed every line
> 3. I used an llm to explore the design space for a patch but wrote it
> manually
> 4. I used an llm to debug or reproduce a kernel issue but then wrote the
> fix manually after fully understanding the defect
> 5. I used an llm to review a patch I wrote
> 6. I used an llm to research some chunk of code while writing a patch
> 7. I used Google while writing a patch and learned something valuable
> from the AI overview at the top
>
> I personally would 100% use the tag for 1 or 2, and have already done
> so. I have not been doing it for 3-5, as I think that will basically
> make every patch llm-assisted to the point of the distinction being
> meaningless. If we should be doing it for 3-5 (or some subset thereof)
> then my mistake and I will certainly start doing so. I would hope most
> people agree 6-7 and similar need no tag.
I think 3-7 don't need the tag.
>
> Similar questions abound if you use an llm to help with writing the
> English text in the patch or emails.
I think this doesn't need the tag, too. Like patches, the user should
completely reviewed and understand the text, though. Without the complete
review, it should not be submmitted at all, regardless of the tag.
>
> I have a feeling that this ambiguity is part of the reason we aren't all
> agreeing on the value of the tag?
I'm not very sure... I don't really feel the question is that difficult and
ambiguous to answer. I may be biased.
Thanks,
SJ
[...]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 21:17 ` Boris Burkov
2026-07-02 23:17 ` SJ Park
@ 2026-07-03 7:05 ` David Hildenbrand (Arm)
2026-07-03 13:12 ` Lorenzo Stoakes
1 sibling, 1 reply; 43+ messages in thread
From: David Hildenbrand (Arm) @ 2026-07-03 7:05 UTC (permalink / raw)
To: Boris Burkov, Lorenzo Stoakes
Cc: Jeff Layton, Greg KH, Laurent Pinchart, Linus Torvalds,
Jonathan Corbet, Justin Stitt, Carlos Maiolino, Jakub Kicinski,
Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On 7/2/26 23:17, Boris Burkov wrote:
> On Thu, Jul 02, 2026 at 05:50:15PM +0100, Lorenzo Stoakes wrote:
>> On Thu, Jul 02, 2026 at 12:48:22PM -0400, Jeff Layton wrote:
>>>
>>> Do we need a tag for this though?
>>>
>>> This seems like the kind of information that we would always require in
>>> the cover letter of a series (or the little place in an individual
>>> patch for comments that don't get merged). That would also allow you to
>>> convey a lot more nuance about how it was used.
>>>
>>> ISTM asking people to disclose LLM usage in a cover letter would give
>>> everyone what they want: Information about whether and possibly how an
>>> LLM was used, and it also wouldn't clutter up the changelogs with these
>>> tags.
>>
>> It's much much clearer and easier to just have a standardised tag for that.
>>
>> You can see that (and grep for that) immediately, vague paragraphs not so much.
>>
>
> At the risk of being pedantic on a point where I think the document is
> kind of lacking:
>
> What level of assistance crosses the bar for an "Assisted-by: LLM" tag?
>
> Some sample levels of assistance to illustrate the point:
>
> 1. I used an llm to one-shot vibe-code a patch
> 2. I used an llm to write a patch but carefully reviewed every line
> 3. I used an llm to explore the design space for a patch but wrote it
> manually
> 4. I used an llm to debug or reproduce a kernel issue but then wrote the
> fix manually after fully understanding the defect
> 5. I used an llm to review a patch I wrote
> 6. I used an llm to research some chunk of code while writing a patch
> 7. I used Google while writing a patch and learned something valuable
> from the AI overview at the top
>
> I personally would 100% use the tag for 1 or 2, and have already done
> so. I have not been doing it for 3-5, as I think that will basically
> make every patch llm-assisted to the point of the distinction being
> meaningless. If we should be doing it for 3-5 (or some subset thereof)
> then my mistake and I will certainly start doing so. I would hope most
> people agree 6-7 and similar need no tag.
>
> Similar questions abound if you use an llm to help with writing the
> English text in the patch or emails.
>
> I have a feeling that this ambiguity is part of the reason we aren't all
> agreeing on the value of the tag?
Yes, I raised something similar as reply to Christian's RFC [1], where I said
that for me the information *how* it was used is much more important:
"
Assisted-by: LLM # translate commit message
Assisted-by: LLM # generate some test cases
Assisted-by: LLM # cleanup logic
Assisted-by: LLM # everything and I have no clue what any in here does
"
That tag is it stands is pretty useless, really.
I assume most people only really use it for something in-between 1 and 2, but
*who knows*.
[1] https://lore.kernel.org/r/5e7b9d23-4291-48fb-bdc6-47db82d33c80@kernel.org
--
Cheers,
David
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 7:05 ` David Hildenbrand (Arm)
@ 2026-07-03 13:12 ` Lorenzo Stoakes
2026-07-03 16:32 ` Laurent Pinchart
2026-07-03 18:26 ` David Hildenbrand (Arm)
0 siblings, 2 replies; 43+ messages in thread
From: Lorenzo Stoakes @ 2026-07-03 13:12 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Boris Burkov, Jeff Layton, Greg KH, Laurent Pinchart,
Linus Torvalds, Jonathan Corbet, Justin Stitt, Carlos Maiolino,
Jakub Kicinski, Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Fri, Jul 03, 2026 at 09:05:58AM +0200, David Hildenbrand (Arm) wrote:
> On 7/2/26 23:17, Boris Burkov wrote:
> > On Thu, Jul 02, 2026 at 05:50:15PM +0100, Lorenzo Stoakes wrote:
> >> On Thu, Jul 02, 2026 at 12:48:22PM -0400, Jeff Layton wrote:
> >>>
> >>> Do we need a tag for this though?
> >>>
> >>> This seems like the kind of information that we would always require in
> >>> the cover letter of a series (or the little place in an individual
> >>> patch for comments that don't get merged). That would also allow you to
> >>> convey a lot more nuance about how it was used.
> >>>
> >>> ISTM asking people to disclose LLM usage in a cover letter would give
> >>> everyone what they want: Information about whether and possibly how an
> >>> LLM was used, and it also wouldn't clutter up the changelogs with these
> >>> tags.
> >>
> >> It's much much clearer and easier to just have a standardised tag for that.
> >>
> >> You can see that (and grep for that) immediately, vague paragraphs not so much.
> >>
> >
> > At the risk of being pedantic on a point where I think the document is
> > kind of lacking:
> >
> > What level of assistance crosses the bar for an "Assisted-by: LLM" tag?
> >
> > Some sample levels of assistance to illustrate the point:
> >
> > 1. I used an llm to one-shot vibe-code a patch
> > 2. I used an llm to write a patch but carefully reviewed every line
> > 3. I used an llm to explore the design space for a patch but wrote it
> > manually
> > 4. I used an llm to debug or reproduce a kernel issue but then wrote the
> > fix manually after fully understanding the defect
> > 5. I used an llm to review a patch I wrote
> > 6. I used an llm to research some chunk of code while writing a patch
> > 7. I used Google while writing a patch and learned something valuable
> > from the AI overview at the top
> >
> > I personally would 100% use the tag for 1 or 2, and have already done
> > so. I have not been doing it for 3-5, as I think that will basically
> > make every patch llm-assisted to the point of the distinction being
> > meaningless. If we should be doing it for 3-5 (or some subset thereof)
> > then my mistake and I will certainly start doing so. I would hope most
> > people agree 6-7 and similar need no tag.
I personally think 1-2 are the only relevant cases.
> >
> > Similar questions abound if you use an llm to help with writing the
> > English text in the patch or emails.
> >
> > I have a feeling that this ambiguity is part of the reason we aren't all
> > agreeing on the value of the tag?
>
> Yes, I raised something similar as reply to Christian's RFC [1], where I said
> that for me the information *how* it was used is much more important:
>
> "
> Assisted-by: LLM # translate commit message
> Assisted-by: LLM # generate some test cases
> Assisted-by: LLM # cleanup logic
> Assisted-by: LLM # everything and I have no clue what any in here does
> "
Yup, and we don't need complicated rules for that just 'document what you used
it for and give a sense of how much'.
It's fuzzy but useful.
>
> That tag is it stands is pretty useless, really.
Not to go over it all again but I disagree, even as it stands, it allows us to
engage in conversation about the LLM usage if admitted, and to point those who
are misbehaving at the rules if not.
And it is a clear way to get the boolean 'is this person saying they used an
LLM'.
But I agree with you it'd be MUCH more useful if we did the above.
I wonder if we could get consensus on adding a section to the doc saying that
it'd be _useful_ to add a comment explaining _what_ you did, and explaining the
concept with some examples?
I can't imagine anybody would disagree with that, and that would get us positive
forward progress.
Then later we could debate the details further?
>
> I assume most people only really use it for something in-between 1 and 2, but
> *who knows*.
>
> [1] https://lore.kernel.org/r/5e7b9d23-4291-48fb-bdc6-47db82d33c80@kernel.org
>
> --
> Cheers,
>
> David
Thanks, Lorenzo
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 13:12 ` Lorenzo Stoakes
@ 2026-07-03 16:32 ` Laurent Pinchart
2026-07-03 18:22 ` David Hildenbrand (Arm)
2026-07-03 18:26 ` David Hildenbrand (Arm)
1 sibling, 1 reply; 43+ messages in thread
From: Laurent Pinchart @ 2026-07-03 16:32 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: David Hildenbrand (Arm), Boris Burkov, Jeff Layton, Greg KH,
Linus Torvalds, Jonathan Corbet, Justin Stitt, Carlos Maiolino,
Jakub Kicinski, Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On Fri, Jul 03, 2026 at 02:12:40PM +0100, Lorenzo Stoakes wrote:
> On Fri, Jul 03, 2026 at 09:05:58AM +0200, David Hildenbrand (Arm) wrote:
> > On 7/2/26 23:17, Boris Burkov wrote:
> > > On Thu, Jul 02, 2026 at 05:50:15PM +0100, Lorenzo Stoakes wrote:
> > >> On Thu, Jul 02, 2026 at 12:48:22PM -0400, Jeff Layton wrote:
> > >>>
> > >>> Do we need a tag for this though?
> > >>>
> > >>> This seems like the kind of information that we would always require in
> > >>> the cover letter of a series (or the little place in an individual
> > >>> patch for comments that don't get merged). That would also allow you to
> > >>> convey a lot more nuance about how it was used.
> > >>>
> > >>> ISTM asking people to disclose LLM usage in a cover letter would give
> > >>> everyone what they want: Information about whether and possibly how an
> > >>> LLM was used, and it also wouldn't clutter up the changelogs with these
> > >>> tags.
> > >>
> > >> It's much much clearer and easier to just have a standardised tag for that.
> > >>
> > >> You can see that (and grep for that) immediately, vague paragraphs not so much.
> > >>
> > >
> > > At the risk of being pedantic on a point where I think the document is
> > > kind of lacking:
> > >
> > > What level of assistance crosses the bar for an "Assisted-by: LLM" tag?
> > >
> > > Some sample levels of assistance to illustrate the point:
> > >
> > > 1. I used an llm to one-shot vibe-code a patch
> > > 2. I used an llm to write a patch but carefully reviewed every line
> > > 3. I used an llm to explore the design space for a patch but wrote it
> > > manually
> > > 4. I used an llm to debug or reproduce a kernel issue but then wrote the
> > > fix manually after fully understanding the defect
> > > 5. I used an llm to review a patch I wrote
> > > 6. I used an llm to research some chunk of code while writing a patch
> > > 7. I used Google while writing a patch and learned something valuable
> > > from the AI overview at the top
> > >
> > > I personally would 100% use the tag for 1 or 2, and have already done
> > > so. I have not been doing it for 3-5, as I think that will basically
> > > make every patch llm-assisted to the point of the distinction being
> > > meaningless. If we should be doing it for 3-5 (or some subset thereof)
> > > then my mistake and I will certainly start doing so. I would hope most
> > > people agree 6-7 and similar need no tag.
>
> I personally think 1-2 are the only relevant cases.
>
> > >
> > > Similar questions abound if you use an llm to help with writing the
> > > English text in the patch or emails.
> > >
> > > I have a feeling that this ambiguity is part of the reason we aren't all
> > > agreeing on the value of the tag?
> >
> > Yes, I raised something similar as reply to Christian's RFC [1], where I said
> > that for me the information *how* it was used is much more important:
> >
> > "
> > Assisted-by: LLM # translate commit message
> > Assisted-by: LLM # generate some test cases
> > Assisted-by: LLM # cleanup logic
> > Assisted-by: LLM # everything and I have no clue what any in here does
> > "
>
> Yup, and we don't need complicated rules for that just 'document what you used
> it for and give a sense of how much'.
>
> It's fuzzy but useful.
>
> >
> > That tag is it stands is pretty useless, really.
>
> Not to go over it all again but I disagree, even as it stands, it allows us to
> engage in conversation about the LLM usage if admitted, and to point those who
> are misbehaving at the rules if not.
>
> And it is a clear way to get the boolean 'is this person saying they used an
> LLM'.
>
> But I agree with you it'd be MUCH more useful if we did the above.
>
> I wonder if we could get consensus on adding a section to the doc saying that
> it'd be _useful_ to add a comment explaining _what_ you did, and explaining the
> concept with some examples?
I'd support a patch that replaces
Assisted-by: Claude:claude-3-opus coccinelle sparse
with
Assisted-by: LLM # generate some test cases
and rewrites the Attribution section of
Documentation/process/coding-assistants.rst accordingly.
I think most people in this mail thread have expressed that how
generative AI was used is the most important information, and several
people (including myself) have expressed a desire to stop the free
advertising. Unless I missed something, I don't think anyone has
expressed an interest in keeping the agent name and model.
> I can't imagine anybody would disagree with that, and that would get us positive
> forward progress.
>
> Then later we could debate the details further?
>
> > I assume most people only really use it for something in-between 1 and 2, but
> > *who knows*.
> >
> > [1] https://lore.kernel.org/r/5e7b9d23-4291-48fb-bdc6-47db82d33c80@kernel.org
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 16:32 ` Laurent Pinchart
@ 2026-07-03 18:22 ` David Hildenbrand (Arm)
0 siblings, 0 replies; 43+ messages in thread
From: David Hildenbrand (Arm) @ 2026-07-03 18:22 UTC (permalink / raw)
To: Laurent Pinchart, Lorenzo Stoakes
Cc: Boris Burkov, Jeff Layton, Greg KH, Linus Torvalds,
Jonathan Corbet, Justin Stitt, Carlos Maiolino, Jakub Kicinski,
Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
On 7/3/26 18:32, Laurent Pinchart wrote:
> On Fri, Jul 03, 2026 at 02:12:40PM +0100, Lorenzo Stoakes wrote:
>> On Fri, Jul 03, 2026 at 09:05:58AM +0200, David Hildenbrand (Arm) wrote:
>>
>> I personally think 1-2 are the only relevant cases.
>>
>>>
>>> Yes, I raised something similar as reply to Christian's RFC [1], where I said
>>> that for me the information *how* it was used is much more important:
>>>
>>> "
>>> Assisted-by: LLM # translate commit message
>>> Assisted-by: LLM # generate some test cases
>>> Assisted-by: LLM # cleanup logic
>>> Assisted-by: LLM # everything and I have no clue what any in here does
>>> "
>>
>> Yup, and we don't need complicated rules for that just 'document what you used
>> it for and give a sense of how much'.
>>
>> It's fuzzy but useful.
>>
>>>
>>> That tag is it stands is pretty useless, really.
>>
>> Not to go over it all again but I disagree, even as it stands, it allows us to
>> engage in conversation about the LLM usage if admitted, and to point those who
>> are misbehaving at the rules if not.
>>
>> And it is a clear way to get the boolean 'is this person saying they used an
>> LLM'.
>>
>> But I agree with you it'd be MUCH more useful if we did the above.
>>
>> I wonder if we could get consensus on adding a section to the doc saying that
>> it'd be _useful_ to add a comment explaining _what_ you did, and explaining the
>> concept with some examples?
>
> I'd support a patch that replaces
>
> Assisted-by: Claude:claude-3-opus coccinelle sparse
>
> with
>
> Assisted-by: LLM # generate some test cases
>
> and rewrites the Attribution section of
> Documentation/process/coding-assistants.rst accordingly.
>
> I think most people in this mail thread have expressed that how
> generative AI was used is the most important information, and several
> people (including myself) have expressed a desire to stop the free
> advertising. Unless I missed something, I don't think anyone has
> expressed an interest in keeping the agent name and model.
Yes, that's something I would enjoy seeing. Who reading along has a problem with
that? (assuming that the tag must stay)
--
Cheers,
David
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-03 13:12 ` Lorenzo Stoakes
2026-07-03 16:32 ` Laurent Pinchart
@ 2026-07-03 18:26 ` David Hildenbrand (Arm)
1 sibling, 0 replies; 43+ messages in thread
From: David Hildenbrand (Arm) @ 2026-07-03 18:26 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Boris Burkov, Jeff Layton, Greg KH, Laurent Pinchart,
Linus Torvalds, Jonathan Corbet, Justin Stitt, Carlos Maiolino,
Jakub Kicinski, Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, Vlastimil Babka, Christian Brauner (Amutable),
workflows, linux-doc, linux-kernel, linux-fsdevel
>>
>> That tag is it stands is pretty useless, really.
>
> Not to go over it all again but I disagree, even as it stands, it allows us to
> engage in conversation about the LLM usage if admitted, and to point those who
> are misbehaving at the rules if not.
Just to comment on that
When I don't see the tag I am clueless *if and how* LLMs were used, in
particular as some subsystems seem to encourage not using them and we even
document it as a "rather nice to have" -- "should".
And if I see the tag, I am clueless *how* LLMs were used.
So I see your point that the tag as it stands helps a little bit, for my
day-to-day work, however, not much, as I really care about the "how". :(
--
Cheers,
David
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH] Documentation: remove the requirement for LLM attribution
2026-07-02 16:50 ` Lorenzo Stoakes
2026-07-02 21:17 ` Boris Burkov
@ 2026-07-02 23:05 ` SJ Park
1 sibling, 0 replies; 43+ messages in thread
From: SJ Park @ 2026-07-02 23:05 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: SJ Park, Jeff Layton, Greg KH, Laurent Pinchart, Linus Torvalds,
Jonathan Corbet, Justin Stitt, Carlos Maiolino, Jakub Kicinski,
Jori Koolstra, Krzysztof Kozlowski, Brian Foster,
Christoph Hellwig, David Disseldorp, Mark Brown, Jani Nikula,
Jens Axboe, David Hildenbrand, Vlastimil Babka,
Christian Brauner (Amutable), workflows, linux-doc, linux-kernel,
linux-fsdevel
On Thu, 2 Jul 2026 17:50:15 +0100 Lorenzo Stoakes <ljs@kernel.org> wrote:
> On Thu, Jul 02, 2026 at 12:48:22PM -0400, Jeff Layton wrote:
> > On Thu, 2026-07-02 at 18:19 +0200, Greg KH wrote:
> > > On Thu, Jul 02, 2026 at 07:13:30PM +0300, Laurent Pinchart wrote:
> > > > On Thu, Jul 02, 2026 at 11:57:46AM -0400, Jeff Layton wrote:
> > > > > On Thu, 2026-07-02 at 17:07 +0200, Greg KH wrote:
> > > > > > On Thu, Jul 02, 2026 at 10:32:48AM -0400, Jeff Layton wrote:
> > > > > > > We've had this requirement in place in the Documentation for several
> > > > > > > months, but it's becoming clear that the signal to noise ratio from this
> > > > > > > is quite low.
> > > > > > >
> > > > > > > 1/ It's not universally followed. While many people do try to attribute
> > > > > > > the LLMs in good faith, not everyone does for various reasons.
> > > > > >
> > > > > > Then let's move to get people to follow it.
> > > > > >
> > > > > > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > > > > >
> > > > > > Who cares, make up a name, all I want is the "signal" that someone is
> > > > > > using a LLM so that I can review it as-such. And if I think someone is
> > > > > > not reporting that, I can ask for them to properly attribute it and if
> > > > > > they lie, well, that's on them.
> > > > > >
> > > > > > > 3/ It's not clear why we want to collect this info in the first place.
> > > > > >
> > > > > > We want to know if a LLM is being used.
> > > > >
> > > > > But why? What do you intend to do with this information?
> > > > >
> > > > > Do you mean to use it as an indicator that the patch should receive
> > > > > "extra" review (or maybe that it should be ignored)? Do you mean to use
> > > > > it to generate some sort of statistics at a later time?
> > > >
> > > > I use the information to decide how to review the patch, and what level
> > > > of priority to give it. For that usage I don't need a tag, but I need
> > > > the information in some human-readable form at patch submission time.
> > >
> > > Same here. I don't care about stats, I care about "how do I review this
> > > patch" and this gives me that signal that I need if faced with a
> > > llm-helped patch.
> > >
> > >
> >
> > Do we need a tag for this though?
> >
> > This seems like the kind of information that we would always require in
> > the cover letter of a series (or the little place in an individual
> > patch for comments that don't get merged). That would also allow you to
> > convey a lot more nuance about how it was used.
> >
> > ISTM asking people to disclose LLM usage in a cover letter would give
> > everyone what they want: Information about whether and possibly how an
> > LLM was used, and it also wouldn't clutter up the changelogs with these
> > tags.
I understand the concern is having the information in the git log. I agree in
a level. I wish cloning linux takes not too long time and huge traffic. I
wish each commit message be lengthy only as much as needed.
>
> It's much much clearer and easier to just have a standardised tag for that.
>
> You can see that (and grep for that) immediately, vague paragraphs not so much.
I also agree having a formal tag can be convenient. LWN's Assisted-by: tag
statistic was interesting enough to make me supporting this idea.
What about keep requesting this formal signature to the submitters, but also
formally allow (or, encourage) subsystem maintainers to remove the tags when
pull-request? That's already allowed, to my understanding and some maintainers
are doing [1] today. That can help preventing the git history of a subsystem
bloating or advertising priorietary companies, as much as the maintainer care.
Meanwhile, we can still get the information at review time, and also after
review from the mail archives. It will still be handy as long as we use tools
like 'lei'. As some maintainers are already removing the tags from the git
log, this may be anyway a better way. Someone may interested in only their
subsystem history, but I find LLM users tend to contribute to multiple
subsystems, so this might actually matters.
It might be too clear to formally document this, though.
[1] https://lore.kernel.org/20260701115302.29c66401@kernel.org
Thanks,
SJ
[...]
^ permalink raw reply [flat|nested] 43+ messages in thread