[PATCH] Documentation: remove the requirement for LLM attribution

[PATCH] Documentation: remove the requirement for LLM attribution

[Jeff Layton]

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.

2/ It basically serves as free advertising for proprietary LLM companies.

3/ It's not clear why we want to collect this info in the first place.

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.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
Christian had proposed watering down the LLM attribution, but I think
it's not productive to try and track this until we have a clearer sense
of what we want to do with this information and how to make it more
reliable.
---
 Documentation/process/coding-assistants.rst  | 22 ----------------------
 Documentation/process/submitting-patches.rst | 10 ----------
 2 files changed, 32 deletions(-)

diff --git a/Documentation/process/coding-assistants.rst b/Documentation/process/coding-assistants.rst
index 899f4459c52d..c4cc0917fc92 100644
--- a/Documentation/process/coding-assistants.rst
+++ b/Documentation/process/coding-assistants.rst
@@ -35,25 +35,3 @@ is responsible for:
 * Ensuring compliance with licensing requirements
 * Adding their own Signed-off-by tag to certify the DCO
 * Taking full responsibility for the contribution
-
-Attribution
-===========
-
-When AI tools contribute to kernel development, proper attribution
-helps track the evolving role of AI in the development process.
-Contributions should include an Assisted-by tag in the following format::
-
-  Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
-
-Where:
-
-* ``AGENT_NAME`` is the name of the AI tool or framework
-* ``MODEL_VERSION`` is the specific model version used
-* ``[TOOL1] [TOOL2]`` are optional specialized analysis tools used
-  (e.g., coccinelle, sparse, smatch, clang-tidy)
-
-Basic development tools (git, gcc, make, editors) should not be listed.
-
-Example::
-
-  Assisted-by: Claude:claude-3-opus coccinelle sparse
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index cc6a1f73d7f2..b74c38aa9770 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -634,16 +634,6 @@ bugzilla.kernel.org is a public place in this sense, but email addresses
 used there are private; so do not expose them in tags, unless the person
 used them in earlier contributions.
 
-Using Assisted-by:
-------------------
-
-If you used any sort of advanced coding tool in the creation of your patch,
-you need to acknowledge that use by adding an Assisted-by tag.  Failure to
-do so may impede the acceptance of your work.  Please see
-Documentation/process/coding-assistants.rst for details regarding the
-acknowledgment of coding assistants.
-
-
 .. _the_canonical_patch_format:
 
 The canonical patch format

---
base-commit: 665159e246749578d4e4bfe106ee3b74edcdab18
change-id: 20260702-aidoc-7e18f221d63a

Best regards,
-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Laurent Pinchart]

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.
> 
> 2/ It basically serves as free advertising for proprietary LLM companies.
> 
> 3/ It's not clear why we want to collect this info in the first place.
> 
> 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.
> 
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> Christian had proposed watering down the LLM attribution, but I think
> it's not productive to try and track this until we have a clearer sense
> of what we want to do with this information and how to make it more
> reliable.
> ---
>  Documentation/process/coding-assistants.rst  | 22 ----------------------
>  Documentation/process/submitting-patches.rst | 10 ----------

You're missing scripts/checkpatch.pl.

>  2 files changed, 32 deletions(-)
> 
> diff --git a/Documentation/process/coding-assistants.rst b/Documentation/process/coding-assistants.rst
> index 899f4459c52d..c4cc0917fc92 100644
> --- a/Documentation/process/coding-assistants.rst
> +++ b/Documentation/process/coding-assistants.rst
> @@ -35,25 +35,3 @@ is responsible for:
>  * Ensuring compliance with licensing requirements
>  * Adding their own Signed-off-by tag to certify the DCO
>  * Taking full responsibility for the contribution
> -
> -Attribution
> -===========
> -
> -When AI tools contribute to kernel development, proper attribution
> -helps track the evolving role of AI in the development process.
> -Contributions should include an Assisted-by tag in the following format::
> -
> -  Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
> -
> -Where:
> -
> -* ``AGENT_NAME`` is the name of the AI tool or framework
> -* ``MODEL_VERSION`` is the specific model version used
> -* ``[TOOL1] [TOOL2]`` are optional specialized analysis tools used
> -  (e.g., coccinelle, sparse, smatch, clang-tidy)
> -
> -Basic development tools (git, gcc, make, editors) should not be listed.
> -
> -Example::
> -
> -  Assisted-by: Claude:claude-3-opus coccinelle sparse

Documentation/process/generated-content.rst still clearly requests
contributors to disclose usage of code-generation tools. Even if we drop
the Assisted-by tag, I think it is useful to mention the requirement
here (probably including a link to generated-content.rst).

> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index cc6a1f73d7f2..b74c38aa9770 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -634,16 +634,6 @@ bugzilla.kernel.org is a public place in this sense, but email addresses
>  used there are private; so do not expose them in tags, unless the person
>  used them in earlier contributions.
>  
> -Using Assisted-by:
> -------------------
> -
> -If you used any sort of advanced coding tool in the creation of your patch,
> -you need to acknowledge that use by adding an Assisted-by tag.  Failure to
> -do so may impede the acceptance of your work.  Please see
> -Documentation/process/coding-assistants.rst for details regarding the
> -acknowledgment of coding assistants.
> -
> -
>  .. _the_canonical_patch_format:
>  
>  The canonical patch format
> 
> ---
> base-commit: 665159e246749578d4e4bfe106ee3b74edcdab18
> change-id: 20260702-aidoc-7e18f221d63a

-- 
Regards,

Laurent Pinchart

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Lorenzo Stoakes]

I'm a little surprised I'm cc'd on this :) I'm not entirely sure if my pushing
back on this is going to mean anything but I suppose here goes nothing.

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.

Does something not being universally followed therefore make it worthless?

You really have to explain that, because this is literally true of any rule
whatsoever we might have in the kernel, should we drop all of them?

I think you should replace this with a cogent argument such as that you feel it
is not being used in the _majority_ of cases or is very rarely used, and that
value is in your view not there.

>
> 2/ It basically serves as free advertising for proprietary LLM companies.

I agree with this point, we should drop the model.

>
> 3/ It's not clear why we want to collect this info in the first place.

Well I made arguments on the other thread, but to repeat:

- It makes it easier to engage with people when they do ack it.

- It makes it far quicker to be able to do so.

- There's a barrier to mentioning an LLM if it's not provided - people can get
  upset, or it can cause issues to raise it as a concern.

- Even if it's only there in _some_ cases, it makes _those_ cases easier to deal
  with.

- It provides some (incomplete) data that might make it easier to deal with
  bug-causing patches.

- It provides some (incomplete) data on bug rates with/without LLMs.

I do agree they're far far less useful when there's not some indication of how
much of the patch was LLM-generated.

Their usefulness is obviously deeply far from perfect, but not zero.

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

I feel there are purposes. Perhaps the argument is stronger for having the tags
on submissions rather than actually in-tree, however.

>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

I think simplifying by requiring only 'LLM' and adding a line simply suggesting
a comment giving a sense of how much was used, and then perhaps a paragraph saying

	Subsystems may vary in their acceptance of this patch blah blah blah

Could be a compromise?

> ---
> Christian had proposed watering down the LLM attribution, but I think
> it's not productive to try and track this until we have a clearer sense
> of what we want to do with this information and how to make it more
> reliable.

Well he's moved now to stridently saying we should do what you're doing here so
presumably you're now in alignment.

> ---
>  Documentation/process/coding-assistants.rst  | 22 ----------------------
>  Documentation/process/submitting-patches.rst | 10 ----------
>  2 files changed, 32 deletions(-)
>
> diff --git a/Documentation/process/coding-assistants.rst b/Documentation/process/coding-assistants.rst
> index 899f4459c52d..c4cc0917fc92 100644
> --- a/Documentation/process/coding-assistants.rst
> +++ b/Documentation/process/coding-assistants.rst
> @@ -35,25 +35,3 @@ is responsible for:
>  * Ensuring compliance with licensing requirements
>  * Adding their own Signed-off-by tag to certify the DCO
>  * Taking full responsibility for the contribution
> -
> -Attribution
> -===========
> -
> -When AI tools contribute to kernel development, proper attribution
> -helps track the evolving role of AI in the development process.
> -Contributions should include an Assisted-by tag in the following format::
> -
> -  Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
> -
> -Where:
> -
> -* ``AGENT_NAME`` is the name of the AI tool or framework
> -* ``MODEL_VERSION`` is the specific model version used
> -* ``[TOOL1] [TOOL2]`` are optional specialized analysis tools used
> -  (e.g., coccinelle, sparse, smatch, clang-tidy)
> -
> -Basic development tools (git, gcc, make, editors) should not be listed.
> -
> -Example::
> -
> -  Assisted-by: Claude:claude-3-opus coccinelle sparse
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index cc6a1f73d7f2..b74c38aa9770 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -634,16 +634,6 @@ bugzilla.kernel.org is a public place in this sense, but email addresses
>  used there are private; so do not expose them in tags, unless the person
>  used them in earlier contributions.
>
> -Using Assisted-by:
> -------------------
> -
> -If you used any sort of advanced coding tool in the creation of your patch,
> -you need to acknowledge that use by adding an Assisted-by tag.  Failure to
> -do so may impede the acceptance of your work.  Please see
> -Documentation/process/coding-assistants.rst for details regarding the
> -acknowledgment of coding assistants.
> -
> -
>  .. _the_canonical_patch_format:
>
>  The canonical patch format
>
> ---
> base-commit: 665159e246749578d4e4bfe106ee3b74edcdab18
> change-id: 20260702-aidoc-7e18f221d63a
>
> Best regards,
> --
> Jeff Layton <jlayton@kernel.org>
>

Thanks, Lorenzo

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Lorenzo Stoakes]

On Thu, Jul 02, 2026 at 05:53:22PM +0300, Laurent Pinchart 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.
> >
> > 2/ It basically serves as free advertising for proprietary LLM companies.
> >
> > 3/ It's not clear why we want to collect this info in the first place.
> >
> > 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.
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > Christian had proposed watering down the LLM attribution, but I think
> > it's not productive to try and track this until we have a clearer sense
> > of what we want to do with this information and how to make it more
> > reliable.
> > ---
> >  Documentation/process/coding-assistants.rst  | 22 ----------------------
> >  Documentation/process/submitting-patches.rst | 10 ----------
>
> You're missing scripts/checkpatch.pl.
>
> >  2 files changed, 32 deletions(-)
> >
> > diff --git a/Documentation/process/coding-assistants.rst b/Documentation/process/coding-assistants.rst
> > index 899f4459c52d..c4cc0917fc92 100644
> > --- a/Documentation/process/coding-assistants.rst
> > +++ b/Documentation/process/coding-assistants.rst
> > @@ -35,25 +35,3 @@ is responsible for:
> >  * Ensuring compliance with licensing requirements
> >  * Adding their own Signed-off-by tag to certify the DCO
> >  * Taking full responsibility for the contribution
> > -
> > -Attribution
> > -===========
> > -
> > -When AI tools contribute to kernel development, proper attribution
> > -helps track the evolving role of AI in the development process.
> > -Contributions should include an Assisted-by tag in the following format::
> > -
> > -  Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
> > -
> > -Where:
> > -
> > -* ``AGENT_NAME`` is the name of the AI tool or framework
> > -* ``MODEL_VERSION`` is the specific model version used
> > -* ``[TOOL1] [TOOL2]`` are optional specialized analysis tools used
> > -  (e.g., coccinelle, sparse, smatch, clang-tidy)
> > -
> > -Basic development tools (git, gcc, make, editors) should not be listed.
> > -
> > -Example::
> > -
> > -  Assisted-by: Claude:claude-3-opus coccinelle sparse
>
> Documentation/process/generated-content.rst still clearly requests
> contributors to disclose usage of code-generation tools. Even if we drop
> the Assisted-by tag, I think it is useful to mention the requirement
> here (probably including a link to generated-content.rst).

I mean this is what I proposed, but Christian was opposed to me doing so?

I guess if this patch is going in over my objections anyway you may as well do
what I suggested with it, but I was going to send a separate patch providing a
link.

Let me know if it's not worth my time doing that.

>
> > diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> > index cc6a1f73d7f2..b74c38aa9770 100644
> > --- a/Documentation/process/submitting-patches.rst
> > +++ b/Documentation/process/submitting-patches.rst
> > @@ -634,16 +634,6 @@ bugzilla.kernel.org is a public place in this sense, but email addresses
> >  used there are private; so do not expose them in tags, unless the person
> >  used them in earlier contributions.
> >
> > -Using Assisted-by:
> > -------------------
> > -
> > -If you used any sort of advanced coding tool in the creation of your patch,
> > -you need to acknowledge that use by adding an Assisted-by tag.  Failure to
> > -do so may impede the acceptance of your work.  Please see
> > -Documentation/process/coding-assistants.rst for details regarding the
> > -acknowledgment of coding assistants.
> > -
> > -
> >  .. _the_canonical_patch_format:
> >
> >  The canonical patch format
> >
> > ---
> > base-commit: 665159e246749578d4e4bfe106ee3b74edcdab18
> > change-id: 20260702-aidoc-7e18f221d63a
>
> --
> Regards,
>
> Laurent Pinchart

Thanks, Lorenzo

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Jeff Layton]

On Thu, 2026-07-02 at 17:53 +0300, Laurent Pinchart 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.
> > 
> > 2/ It basically serves as free advertising for proprietary LLM companies.
> > 
> > 3/ It's not clear why we want to collect this info in the first place.
> > 
> > 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.
> > 
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > Christian had proposed watering down the LLM attribution, but I think
> > it's not productive to try and track this until we have a clearer sense
> > of what we want to do with this information and how to make it more
> > reliable.
> > ---
> >  Documentation/process/coding-assistants.rst  | 22 ----------------------
> >  Documentation/process/submitting-patches.rst | 10 ----------
> 
> You're missing scripts/checkpatch.pl.
> 
> >  2 files changed, 32 deletions(-)
> > 
> > diff --git a/Documentation/process/coding-assistants.rst b/Documentation/process/coding-assistants.rst
> > index 899f4459c52d..c4cc0917fc92 100644
> > --- a/Documentation/process/coding-assistants.rst
> > +++ b/Documentation/process/coding-assistants.rst
> > @@ -35,25 +35,3 @@ is responsible for:
> >  * Ensuring compliance with licensing requirements
> >  * Adding their own Signed-off-by tag to certify the DCO
> >  * Taking full responsibility for the contribution
> > -
> > -Attribution
> > -===========
> > -
> > -When AI tools contribute to kernel development, proper attribution
> > -helps track the evolving role of AI in the development process.
> > -Contributions should include an Assisted-by tag in the following format::
> > -
> > -  Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
> > -
> > -Where:
> > -
> > -* ``AGENT_NAME`` is the name of the AI tool or framework
> > -* ``MODEL_VERSION`` is the specific model version used
> > -* ``[TOOL1] [TOOL2]`` are optional specialized analysis tools used
> > -  (e.g., coccinelle, sparse, smatch, clang-tidy)
> > -
> > -Basic development tools (git, gcc, make, editors) should not be listed.
> > -
> > -Example::
> > -
> > -  Assisted-by: Claude:claude-3-opus coccinelle sparse
> 
> Documentation/process/generated-content.rst still clearly requests
> contributors to disclose usage of code-generation tools. Even if we drop
> the Assisted-by tag, I think it is useful to mention the requirement
> here (probably including a link to generated-content.rst).
> 

Fair point. Maybe we should keep the Attribution section then, and give
it some brief text like:

"Contributions developed with LLM help should also follow the
guidelines outlined in the generated-content document."

With a link to generated-content.rst?


> > diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> > index cc6a1f73d7f2..b74c38aa9770 100644
> > --- a/Documentation/process/submitting-patches.rst
> > +++ b/Documentation/process/submitting-patches.rst
> > @@ -634,16 +634,6 @@ bugzilla.kernel.org is a public place in this sense, but email addresses
> >  used there are private; so do not expose them in tags, unless the person
> >  used them in earlier contributions.
> >  
> > -Using Assisted-by:
> > -------------------
> > -
> > -If you used any sort of advanced coding tool in the creation of your patch,
> > -you need to acknowledge that use by adding an Assisted-by tag.  Failure to
> > -do so may impede the acceptance of your work.  Please see
> > -Documentation/process/coding-assistants.rst for details regarding the
> > -acknowledgment of coding assistants.
> > -
> > -
> >  .. _the_canonical_patch_format:
> >  
> >  The canonical patch format
> > 
> > ---
> > base-commit: 665159e246749578d4e4bfe106ee3b74edcdab18
> > change-id: 20260702-aidoc-7e18f221d63a

-- 
Jeff Layton <jlayton@kernel.org>

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Greg KH]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Lorenzo Stoakes]

On Thu, Jul 02, 2026 at 11:02:19AM -0400, Jeff Layton wrote:
> On Thu, 2026-07-02 at 17:53 +0300, Laurent Pinchart 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.
> > >
> > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > >
> > > 3/ It's not clear why we want to collect this info in the first place.
> > >
> > > 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.
> > >
> > > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > > ---
> > > Christian had proposed watering down the LLM attribution, but I think
> > > it's not productive to try and track this until we have a clearer sense
> > > of what we want to do with this information and how to make it more
> > > reliable.
> > > ---
> > >  Documentation/process/coding-assistants.rst  | 22 ----------------------
> > >  Documentation/process/submitting-patches.rst | 10 ----------
> >
> > You're missing scripts/checkpatch.pl.
> >
> > >  2 files changed, 32 deletions(-)
> > >
> > > diff --git a/Documentation/process/coding-assistants.rst b/Documentation/process/coding-assistants.rst
> > > index 899f4459c52d..c4cc0917fc92 100644
> > > --- a/Documentation/process/coding-assistants.rst
> > > +++ b/Documentation/process/coding-assistants.rst
> > > @@ -35,25 +35,3 @@ is responsible for:
> > >  * Ensuring compliance with licensing requirements
> > >  * Adding their own Signed-off-by tag to certify the DCO
> > >  * Taking full responsibility for the contribution
> > > -
> > > -Attribution
> > > -===========
> > > -
> > > -When AI tools contribute to kernel development, proper attribution
> > > -helps track the evolving role of AI in the development process.
> > > -Contributions should include an Assisted-by tag in the following format::
> > > -
> > > -  Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
> > > -
> > > -Where:
> > > -
> > > -* ``AGENT_NAME`` is the name of the AI tool or framework
> > > -* ``MODEL_VERSION`` is the specific model version used
> > > -* ``[TOOL1] [TOOL2]`` are optional specialized analysis tools used
> > > -  (e.g., coccinelle, sparse, smatch, clang-tidy)
> > > -
> > > -Basic development tools (git, gcc, make, editors) should not be listed.
> > > -
> > > -Example::
> > > -
> > > -  Assisted-by: Claude:claude-3-opus coccinelle sparse
> >
> > Documentation/process/generated-content.rst still clearly requests
> > contributors to disclose usage of code-generation tools. Even if we drop
> > the Assisted-by tag, I think it is useful to mention the requirement
> > here (probably including a link to generated-content.rst).
> >
>
> Fair point. Maybe we should keep the Attribution section then, and give
> it some brief text like:

I really do not understand how requiring disclosure but not tags isn't a
contradictory position?

If disclosure via tags is worthless because people don't always do it, how is
disclosure using rules not also worthless?

Tags seem like the clearest possible means of expressing this so now I'm
confused as to the point being argued here...

>
> "Contributions developed with LLM help should also follow the
> guidelines outlined in the generated-content document."
>
> With a link to generated-content.rst?

Again I proposed to send this patch alrady but oppose your one, so how should we
move forwards?

If the patch will land over my objections then fine I can save some time, but if
it's in question, maybe I can just do that bit separately?...

>
>
> > > diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> > > index cc6a1f73d7f2..b74c38aa9770 100644
> > > --- a/Documentation/process/submitting-patches.rst
> > > +++ b/Documentation/process/submitting-patches.rst
> > > @@ -634,16 +634,6 @@ bugzilla.kernel.org is a public place in this sense, but email addresses
> > >  used there are private; so do not expose them in tags, unless the person
> > >  used them in earlier contributions.
> > >
> > > -Using Assisted-by:
> > > -------------------
> > > -
> > > -If you used any sort of advanced coding tool in the creation of your patch,
> > > -you need to acknowledge that use by adding an Assisted-by tag.  Failure to
> > > -do so may impede the acceptance of your work.  Please see
> > > -Documentation/process/coding-assistants.rst for details regarding the
> > > -acknowledgment of coding assistants.
> > > -
> > > -
> > >  .. _the_canonical_patch_format:
> > >
> > >  The canonical patch format
> > >
> > > ---
> > > base-commit: 665159e246749578d4e4bfe106ee3b74edcdab18
> > > change-id: 20260702-aidoc-7e18f221d63a
>
> --
> Jeff Layton <jlayton@kernel.org>

Thanks, Lorenzo

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Jonathan Corbet]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Lorenzo Stoakes]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Lorenzo Stoakes]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Laurent Pinchart]

Hi Lorenzo,

On Thu, Jul 02, 2026 at 03:57:11PM +0100, Lorenzo Stoakes wrote:
> I'm a little surprised I'm cc'd on this :) I'm not entirely sure if my pushing
> back on this is going to mean anything but I suppose here goes nothing.
> 
> 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.
> 
> Does something not being universally followed therefore make it worthless?
> 
> You really have to explain that, because this is literally true of any rule
> whatsoever we might have in the kernel, should we drop all of them?
> 
> I think you should replace this with a cogent argument such as that you feel it
> is not being used in the _majority_ of cases or is very rarely used, and that
> value is in your view not there.
> 
> >
> > 2/ It basically serves as free advertising for proprietary LLM companies.
> 
> I agree with this point, we should drop the model.
> 
> > 3/ It's not clear why we want to collect this info in the first place.
> 
> Well I made arguments on the other thread, but to repeat:
> 
> - It makes it easier to engage with people when they do ack it.
> 
> - It makes it far quicker to be able to do so.
> 
> - There's a barrier to mentioning an LLM if it's not provided - people can get
>   upset, or it can cause issues to raise it as a concern.
> 
> - Even if it's only there in _some_ cases, it makes _those_ cases easier to deal
>   with.

As far as I understand, all the above arguments would also be addressed
with either a free-formed mention of LLM usage, or a formal
"non-advertising" tag that is not merged in the kernel history, right ?

> - It provides some (incomplete) data that might make it easier to deal with
>   bug-causing patches.
> 
> - It provides some (incomplete) data on bug rates with/without LLMs.

For those two I suppose a machine-parseable tag in the git history could
improve things slightly compared to information provided in the patch
submission that would not get recorded in the history.

Is this why you have a preference for a formal tag compared to a
free-formed mention ?

> I do agree they're far far less useful when there's not some indication of how
> much of the patch was LLM-generated.
> 
> Their usefulness is obviously deeply far from perfect, but not zero.
> 
> > 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.
> 
> I feel there are purposes. Perhaps the argument is stronger for having the tags
> on submissions rather than actually in-tree, however.

I really think we need to have the information at submission. I think I
have a slight preference for not recording it in the kernel tree, but
only slight.

> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> 
> I think simplifying by requiring only 'LLM' and adding a line simply suggesting
> a comment giving a sense of how much was used, and then perhaps a paragraph saying
> 
> 	Subsystems may vary in their acceptance of this patch blah blah blah
> 
> Could be a compromise?
> 
> > ---
> > Christian had proposed watering down the LLM attribution, but I think
> > it's not productive to try and track this until we have a clearer sense
> > of what we want to do with this information and how to make it more
> > reliable.
> 
> Well he's moved now to stridently saying we should do what you're doing here so
> presumably you're now in alignment.
> 
> > ---
> >  Documentation/process/coding-assistants.rst  | 22 ----------------------
> >  Documentation/process/submitting-patches.rst | 10 ----------
> >  2 files changed, 32 deletions(-)
> >
> > diff --git a/Documentation/process/coding-assistants.rst b/Documentation/process/coding-assistants.rst
> > index 899f4459c52d..c4cc0917fc92 100644
> > --- a/Documentation/process/coding-assistants.rst
> > +++ b/Documentation/process/coding-assistants.rst
> > @@ -35,25 +35,3 @@ is responsible for:
> >  * Ensuring compliance with licensing requirements
> >  * Adding their own Signed-off-by tag to certify the DCO
> >  * Taking full responsibility for the contribution
> > -
> > -Attribution
> > -===========
> > -
> > -When AI tools contribute to kernel development, proper attribution
> > -helps track the evolving role of AI in the development process.
> > -Contributions should include an Assisted-by tag in the following format::
> > -
> > -  Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
> > -
> > -Where:
> > -
> > -* ``AGENT_NAME`` is the name of the AI tool or framework
> > -* ``MODEL_VERSION`` is the specific model version used
> > -* ``[TOOL1] [TOOL2]`` are optional specialized analysis tools used
> > -  (e.g., coccinelle, sparse, smatch, clang-tidy)
> > -
> > -Basic development tools (git, gcc, make, editors) should not be listed.
> > -
> > -Example::
> > -
> > -  Assisted-by: Claude:claude-3-opus coccinelle sparse
> > diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> > index cc6a1f73d7f2..b74c38aa9770 100644
> > --- a/Documentation/process/submitting-patches.rst
> > +++ b/Documentation/process/submitting-patches.rst
> > @@ -634,16 +634,6 @@ bugzilla.kernel.org is a public place in this sense, but email addresses
> >  used there are private; so do not expose them in tags, unless the person
> >  used them in earlier contributions.
> >
> > -Using Assisted-by:
> > -------------------
> > -
> > -If you used any sort of advanced coding tool in the creation of your patch,
> > -you need to acknowledge that use by adding an Assisted-by tag.  Failure to
> > -do so may impede the acceptance of your work.  Please see
> > -Documentation/process/coding-assistants.rst for details regarding the
> > -acknowledgment of coding assistants.
> > -
> > -
> >  .. _the_canonical_patch_format:
> >
> >  The canonical patch format
> >
> > ---
> > base-commit: 665159e246749578d4e4bfe106ee3b74edcdab18
> > change-id: 20260702-aidoc-7e18f221d63a

-- 
Regards,

Laurent Pinchart

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Jori Koolstra]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Lorenzo Stoakes]

On Thu, Jul 02, 2026 at 06:28:15PM +0300, Laurent Pinchart wrote:
> Hi Lorenzo,
>
> On Thu, Jul 02, 2026 at 03:57:11PM +0100, Lorenzo Stoakes wrote:
> > I'm a little surprised I'm cc'd on this :) I'm not entirely sure if my pushing
> > back on this is going to mean anything but I suppose here goes nothing.
> >
> > 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.
> >
> > Does something not being universally followed therefore make it worthless?
> >
> > You really have to explain that, because this is literally true of any rule
> > whatsoever we might have in the kernel, should we drop all of them?
> >
> > I think you should replace this with a cogent argument such as that you feel it
> > is not being used in the _majority_ of cases or is very rarely used, and that
> > value is in your view not there.
> >
> > >
> > > 2/ It basically serves as free advertising for proprietary LLM companies.
> >
> > I agree with this point, we should drop the model.
> >
> > > 3/ It's not clear why we want to collect this info in the first place.
> >
> > Well I made arguments on the other thread, but to repeat:
> >
> > - It makes it easier to engage with people when they do ack it.
> >
> > - It makes it far quicker to be able to do so.
> >
> > - There's a barrier to mentioning an LLM if it's not provided - people can get
> >   upset, or it can cause issues to raise it as a concern.
> >
> > - Even if it's only there in _some_ cases, it makes _those_ cases easier to deal
> >   with.
>
> As far as I understand, all the above arguments would also be addressed
> with either a free-formed mention of LLM usage, or a formal
> "non-advertising" tag that is not merged in the kernel history, right ?

Well I prefer a tag for reasons below. I'm fine with non-advertising yeah.

>
> > - It provides some (incomplete) data that might make it easier to deal with
> >   bug-causing patches.
> >
> > - It provides some (incomplete) data on bug rates with/without LLMs.
>
> For those two I suppose a machine-parseable tag in the git history could
> improve things slightly compared to information provided in the patch
> submission that would not get recorded in the history.

Yeah, again I could live without it being in the tree. I think there's some
advantages though.

See below for tag argument.

>
> Is this why you have a preference for a formal tag compared to a
> free-formed mention ?
>
> > I do agree they're far far less useful when there's not some indication of how
> > much of the patch was LLM-generated.
> >
> > Their usefulness is obviously deeply far from perfect, but not zero.
> >
> > > 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.
> >
> > I feel there are purposes. Perhaps the argument is stronger for having the tags
> > on submissions rather than actually in-tree, however.
>
> I really think we need to have the information at submission. I think I
> have a slight preference for not recording it in the kernel tree, but
> only slight.

It seems we are more in agreement than it seems :)

I prefer a tag as it's clear cut and easily greppable and easily noticeable.

If it's words it can be vague or be unclear or inconsistent and you might miss
etc.

So I have a strong preference for a tag, would love to add details about how
much LLM done (that'll be vague obviously + have grey lines).

I agree gettig rid of model is worthwhile but I'm not bothered if we don't do
that.

Thanks, Lorenzo

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Laurent Pinchart]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Lorenzo Stoakes]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Laurent Pinchart]

On Thu, Jul 02, 2026 at 04:36:20PM +0100, Lorenzo Stoakes wrote:
> On Thu, Jul 02, 2026 at 06:28:15PM +0300, Laurent Pinchart wrote:
> > Hi Lorenzo,
> >
> > On Thu, Jul 02, 2026 at 03:57:11PM +0100, Lorenzo Stoakes wrote:
> > > I'm a little surprised I'm cc'd on this :) I'm not entirely sure if my pushing
> > > back on this is going to mean anything but I suppose here goes nothing.
> > >
> > > 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.
> > >
> > > Does something not being universally followed therefore make it worthless?
> > >
> > > You really have to explain that, because this is literally true of any rule
> > > whatsoever we might have in the kernel, should we drop all of them?
> > >
> > > I think you should replace this with a cogent argument such as that you feel it
> > > is not being used in the _majority_ of cases or is very rarely used, and that
> > > value is in your view not there.
> > >
> > > >
> > > > 2/ It basically serves as free advertising for proprietary LLM companies.
> > >
> > > I agree with this point, we should drop the model.
> > >
> > > > 3/ It's not clear why we want to collect this info in the first place.
> > >
> > > Well I made arguments on the other thread, but to repeat:
> > >
> > > - It makes it easier to engage with people when they do ack it.
> > >
> > > - It makes it far quicker to be able to do so.
> > >
> > > - There's a barrier to mentioning an LLM if it's not provided - people can get
> > >   upset, or it can cause issues to raise it as a concern.
> > >
> > > - Even if it's only there in _some_ cases, it makes _those_ cases easier to deal
> > >   with.
> >
> > As far as I understand, all the above arguments would also be addressed
> > with either a free-formed mention of LLM usage, or a formal
> > "non-advertising" tag that is not merged in the kernel history, right ?
> 
> Well I prefer a tag for reasons below. I'm fine with non-advertising yeah.
> 
> > > - It provides some (incomplete) data that might make it easier to deal with
> > >   bug-causing patches.
> > >
> > > - It provides some (incomplete) data on bug rates with/without LLMs.
> >
> > For those two I suppose a machine-parseable tag in the git history could
> > improve things slightly compared to information provided in the patch
> > submission that would not get recorded in the history.
> 
> Yeah, again I could live without it being in the tree. I think there's some
> advantages though.
> 
> See below for tag argument.
> 
> > Is this why you have a preference for a formal tag compared to a
> > free-formed mention ?
> >
> > > I do agree they're far far less useful when there's not some indication of how
> > > much of the patch was LLM-generated.
> > >
> > > Their usefulness is obviously deeply far from perfect, but not zero.
> > >
> > > > 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.
> > >
> > > I feel there are purposes. Perhaps the argument is stronger for having the tags
> > > on submissions rather than actually in-tree, however.
> >
> > I really think we need to have the information at submission. I think I
> > have a slight preference for not recording it in the kernel tree, but
> > only slight.
> 
> It seems we are more in agreement than it seems :)

I knew we were :-)

> I prefer a tag as it's clear cut and easily greppable and easily noticeable.
> 
> If it's words it can be vague or be unclear or inconsistent and you might miss
> etc.
> 
> So I have a strong preference for a tag, would love to add details about how
> much LLM done (that'll be vague obviously + have grey lines).

I have a slight preference for not recording that in the git history,
but I can live with either.

> I agree gettig rid of model is worthwhile but I'm not bothered if we don't do
> that.

There I have a very strong preference for stopping free advertising.

-- 
Regards,

Laurent Pinchart

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Jeff Layton]

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>

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Chuck Lever]

On Thu, Jul 2, 2026, at 10:32 AM, 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.
>
> 2/ It basically serves as free advertising for proprietary LLM companies.
>
> 3/ It's not clear why we want to collect this info in the first place.
>
> 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.
>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> Christian had proposed watering down the LLM attribution, but I think
> it's not productive to try and track this until we have a clearer sense
> of what we want to do with this information and how to make it more
> reliable.

I agree that the current tagging system is flawed and almost useless
for real analysis -- self-reporting and a nebulous definition of what
"LLM was used" actually means are red flags for any data scientist.

I don't have a stand on whether the tagging should be removed or fixed.
But today I ignore it (my 2-cents US) for these reasons.

-- 
Chuck Lever

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Laurent Pinchart]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Lorenzo Stoakes]

On Thu, Jul 02, 2026 at 12:11:20PM -0400, Chuck Lever wrote:
>
>
> On Thu, Jul 2, 2026, at 10:32 AM, 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.
> >
> > 2/ It basically serves as free advertising for proprietary LLM companies.
> >
> > 3/ It's not clear why we want to collect this info in the first place.
> >
> > 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.
> >
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > Christian had proposed watering down the LLM attribution, but I think
> > it's not productive to try and track this until we have a clearer sense
> > of what we want to do with this information and how to make it more
> > reliable.
>
> I agree that the current tagging system is flawed and almost useless
> for real analysis -- self-reporting and a nebulous definition of what
> "LLM was used" actually means are red flags for any data scientist.
>
> I don't have a stand on whether the tagging should be removed or fixed.
> But today I ignore it (my 2-cents US) for these reasons.

Oh no doubt they have highly dubious value as _data_.

But they are useful for practical purposes :) i.e. 'ok I can talk about the
LLM-ness here without it being quite so aggressive to do so because it's
admitted'.

And also political value in that 'here is how you are supposed to do it'
vs. <how you did it>.

I think there's definite practical human stuff that they provide sufficient for
there to be value here, and I've found that in practice also :)

(Though of course it's far far from resolving how we deal with the unattributed
stuff, which remains an ongoing issue!)

>
> --
> Chuck Lever

Cheers, Lorenzo

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Greg KH]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Laurent Pinchart]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Jeff Layton]

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>

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Lorenzo Stoakes]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Andreas Dilger]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Boris Burkov]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[SJ Park]

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

[...]

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[SJ Park]

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

[...]

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Theodore Tso]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Greg KH]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[David Hildenbrand (Arm)]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[David Hildenbrand (Arm)]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Greg KH]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[David Hildenbrand (Arm)]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Theodore Tso]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Jori Koolstra]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Laurent Pinchart]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Jori Koolstra]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Lorenzo Stoakes]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Andreas Dilger]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[Laurent Pinchart]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[David Hildenbrand (Arm)]

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

Re: [PATCH] Documentation: remove the requirement for LLM attribution

[David Hildenbrand (Arm)]

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