[MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Jonathan Corbet]

The use of LLMs in the development process appears to be a clear theme for
the upcoming summit.  On top of what others have already suggested, I think
we may want to consider these questions:

- Do we want to continue naming specific LLMs in the Assisted-by tags, or
  put something more generic?  I *think* that this thread:

    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/

  reached a consensus that "Assisted-by: LLM" was better than what we
  require now, but it might be good to ratify that in this setting.

- There is a lot of LLM-generated code that lacks an Assisted-by
  disclosure.  Often, that seems to be the result of ignorance of the
  rules; those contributors will start adding the tags when informed of the
  requirement.  But others just lie about it.  A rule that is widely
  ignored does not help anybody.  Can we come up with a way to get better
  compliance, or should we just drop the tag entirely?

- There are many first-time contributors coming in with LLM-generated
  patches.  At times, I could swear that every one of them is focused on
  documentation typos, but the truth of the matter is that they are
  reaching into subsystems all over the kernel.  We have some brand-new
  contributors making significant changes to dozens of subsystems.  An
  experienced developer would be hard-put to truly understand what those
  changes are doing; a newcomer is unlikely to have that understanding,
  and is unlikely to be around to fix eventual problems.

  Our maintainers are not scaling to handle this new flood, and I fear we
  are going to see some unfortunate things merged.  One LLM-driven newcomer
  recently nearly succeeded in establishing himself as the maintainer of
  lib/.  How do we hold the line against this stuff while remaining open to
  new developers?

- Our process is becoming increasingly dependent on proprietary tools.  We
  have done that before and, in 2005, it went pretty badly for us - and
  could have been worse.  How do we prepare for the inevitable rugpull?  I
  raised this last year, and it was largely brushed off, but I still think
  it's something we should be concerned about.

That's probably enough :)

jon

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Sasha Levin]

On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
>The use of LLMs in the development process appears to be a clear theme for
>the upcoming summit.  On top of what others have already suggested, I think
>we may want to consider these questions:
>
>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
>  put something more generic?  I *think* that this thread:
>
>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
>
>  reached a consensus that "Assisted-by: LLM" was better than what we
>  require now, but it might be good to ratify that in this setting.

So originally I've added the full name of the tool and LLM because there was
interest in a later audit of the tools to determine how useful (or useless)
some of the tools are.

If those folks aren't interested in doing so anymore, then sure - we can drop
it.

But... I find it difficult to see the point of having the tag if we do that.

>- There is a lot of LLM-generated code that lacks an Assisted-by
>  disclosure.  Often, that seems to be the result of ignorance of the
>  rules; those contributors will start adding the tags when informed of the
>  requirement.  But others just lie about it.  A rule that is widely
>  ignored does not help anybody.  Can we come up with a way to get better
>  compliance, or should we just drop the tag entirely?

Similarily, I think that one of the bigger reasons for the tag was fear of the
unknown. We figured that we can tag those commits, and if we ever needed to do
something about it (revert commits because of copyright issues, broken tools,
UMN v2, etc) it would make our job easier.

I think that there's room to improve the machinery here (AGENTS.md in the root,
for example).

>- There are many first-time contributors coming in with LLM-generated
>  patches.  At times, I could swear that every one of them is focused on
>  documentation typos, but the truth of the matter is that they are
>  reaching into subsystems all over the kernel.  We have some brand-new
>  contributors making significant changes to dozens of subsystems.  An
>  experienced developer would be hard-put to truly understand what those
>  changes are doing; a newcomer is unlikely to have that understanding,
>  and is unlikely to be around to fix eventual problems.
>
>  Our maintainers are not scaling to handle this new flood, and I fear we
>  are going to see some unfortunate things merged.  One LLM-driven newcomer
>  recently nearly succeeded in establishing himself as the maintainer of
>  lib/.  How do we hold the line against this stuff while remaining open to
>  new developers?

Shouldn't it be a merits question rather than a tools question?

If the commits are correct, does it matter if they were written with an LLM? we
can insist more on supplying tests and demonstrating correctness, something we
seem to be doing quite rarely right now.

>- Our process is becoming increasingly dependent on proprietary tools.  We
>  have done that before and, in 2005, it went pretty badly for us - and
>  could have been worse.  How do we prepare for the inevitable rugpull?  I
>  raised this last year, and it was largely brushed off, but I still think
>  it's something we should be concerned about.

Are we dependent on them, or do we just find them very useful? If
Claude/Codex/etc goes away next month, will it stall any of our processes?

We have AI reviews, we have many AI tools that help both authors and
maintainers, but I don't think that any of them play an integral part of our
process.

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On Thu, Jul 16, 2026 at 11:28:25AM -0400, Sasha Levin wrote:
> On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:

> > - There are many first-time contributors coming in with LLM-generated
> >  patches.  At times, I could swear that every one of them is focused on

> >  Our maintainers are not scaling to handle this new flood, and I fear we
> >  are going to see some unfortunate things merged.  One LLM-driven newcomer
> >  recently nearly succeeded in establishing himself as the maintainer of
> >  lib/.  How do we hold the line against this stuff while remaining open to
> >  new developers?

> Shouldn't it be a merits question rather than a tools question?

> If the commits are correct, does it matter if they were written with an LLM? we
> can insist more on supplying tests and demonstrating correctness, something we
> seem to be doing quite rarely right now.

The issue (which a number of projects are facing) is as much one of
volume as anything else, the code generation machines are enabling the
generation and submision of volumes of code where things were previously 
constrained by human factors.  It can turn into a bit of a DoS.  I don't
have any particularly bright ideas here but it's definitely a thing.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Sasha Levin]

On Thu, Jul 16, 2026 at 05:08:40PM +0100, Mark Brown wrote:
>On Thu, Jul 16, 2026 at 11:28:25AM -0400, Sasha Levin wrote:
>> On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
>
>> > - There are many first-time contributors coming in with LLM-generated
>> >  patches.  At times, I could swear that every one of them is focused on
>
>> >  Our maintainers are not scaling to handle this new flood, and I fear we
>> >  are going to see some unfortunate things merged.  One LLM-driven newcomer
>> >  recently nearly succeeded in establishing himself as the maintainer of
>> >  lib/.  How do we hold the line against this stuff while remaining open to
>> >  new developers?
>
>> Shouldn't it be a merits question rather than a tools question?
>
>> If the commits are correct, does it matter if they were written with an LLM? we
>> can insist more on supplying tests and demonstrating correctness, something we
>> seem to be doing quite rarely right now.
>
>The issue (which a number of projects are facing) is as much one of
>volume as anything else, the code generation machines are enabling the
>generation and submision of volumes of code where things were previously
>constrained by human factors.  It can turn into a bit of a DoS.  I don't
>have any particularly bright ideas here but it's definitely a thing.

Sure, we're seeing quite the increase in patch submissions, but I'm trying to
argue that the issue isn't a new one: lack of maintainers, trusted reviewers,
and maintainer burnout has been a topic at each kernel summit for as long as I
can remember. AI just kicks it up a notch.

My concern is that if we focus on the AI aspect, we still won't be solving the
underlying issue.

I'm hoping we can figure out how to get maintainers great tooling, testing, and
community, rather than figuring out how to block a developer who uses LLM.
Maybe AI would actually be a great catalyst for that as well?

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Jonathan Corbet]

Sasha Levin <sashal@kernel.org> writes:

> On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
>>The use of LLMs in the development process appears to be a clear theme for
>>the upcoming summit.  On top of what others have already suggested, I think
>>we may want to consider these questions:
>>
>>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
>>  put something more generic?  I *think* that this thread:
>>
>>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
>>
>>  reached a consensus that "Assisted-by: LLM" was better than what we
>>  require now, but it might be good to ratify that in this setting.
>
> So originally I've added the full name of the tool and LLM because there was
> interest in a later audit of the tools to determine how useful (or useless)
> some of the tools are.
>
> If those folks aren't interested in doing so anymore, then sure - we can drop
> it.
>
> But... I find it difficult to see the point of having the tag if we do that.

Folks like Greg have, in the recent past, said that it is useful even
without specific product-name information:

  https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/

>>- There are many first-time contributors coming in with LLM-generated
>>  patches.  At times, I could swear that every one of them is focused on
>>  documentation typos, but the truth of the matter is that they are
>>  reaching into subsystems all over the kernel.  We have some brand-new
>>  contributors making significant changes to dozens of subsystems.  An
>>  experienced developer would be hard-put to truly understand what those
>>  changes are doing; a newcomer is unlikely to have that understanding,
>>  and is unlikely to be around to fix eventual problems.
>>
>>  Our maintainers are not scaling to handle this new flood, and I fear we
>>  are going to see some unfortunate things merged.  One LLM-driven newcomer
>>  recently nearly succeeded in establishing himself as the maintainer of
>>  lib/.  How do we hold the line against this stuff while remaining open to
>>  new developers?
>
> Shouldn't it be a merits question rather than a tools question?
>
> If the commits are correct, does it matter if they were written with
> an LLM? we can insist more on supplying tests and demonstrating
> correctness, something we seem to be doing quite rarely right now.

It's definitely a merit question.  But we're not always all that good at
determining whether a commit is correct, and we depend a lot on the
contributor understanding their work and being around if something goes
wrong with it.  That is part of "merit" too.  How confident are we of
that merit when a brand-new developer makes significant changes to a
dozen or more unrelated subsystems?

>>- Our process is becoming increasingly dependent on proprietary tools.  We
>>  have done that before and, in 2005, it went pretty badly for us - and
>>  could have been worse.  How do we prepare for the inevitable rugpull?  I
>>  raised this last year, and it was largely brushed off, but I still think
>>  it's something we should be concerned about.
>
> Are we dependent on them, or do we just find them very useful? If
> Claude/Codex/etc goes away next month, will it stall any of our processes?
>
> We have AI reviews, we have many AI tools that help both authors and
> maintainers, but I don't think that any of them play an integral part of our
> process.

The related discussions have featured a number of maintainers talking
about how much time Sashiko has saved them.  I believe them.  How long
will it take until nobody does that level of patch review anymore?  What
will we do when the current round of corporate generosity ends and that
tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
like a possibility we should keep in mind.

jon

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Mauro Carvalho Chehab]

On Thu, 16 Jul 2026 12:36:53 -0600
Jonathan Corbet <corbet@lwn.net> wrote:

> Sasha Levin <sashal@kernel.org> writes:
> 
> > On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:  
> >>The use of LLMs in the development process appears to be a clear theme for
> >>the upcoming summit.  On top of what others have already suggested, I think
> >>we may want to consider these questions:
> >>
> >>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
> >>  put something more generic?  I *think* that this thread:
> >>
> >>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
> >>
> >>  reached a consensus that "Assisted-by: LLM" was better than what we
> >>  require now, but it might be good to ratify that in this setting.  
> >
> > So originally I've added the full name of the tool and LLM because there was
> > interest in a later audit of the tools to determine how useful (or useless)
> > some of the tools are.
> >
> > If those folks aren't interested in doing so anymore, then sure - we can drop
> > it.
> >
> > But... I find it difficult to see the point of having the tag if we do that.  
> 
> Folks like Greg have, in the recent past, said that it is useful even
> without specific product-name information:
> 
>   https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/

I never saw any merit on having such tag: it doesn't help reviewers
and doesn't provide any useful information at the git history. The
only think they eventually allow is for someone to reject a patch
without actually looking on it.

What we need to ensure is that:
1. the patch is good;
2. author carefully reviewed/modified it and not just did vibe-coding;
3. the author understands the proposed code.

Unfortunately, (2) and (3)s easily said than done as technology avances,
though.

Yet, I recently saw a patch series that sounded to be produced by vibe
coding, probably generated by some proprietary paid model. That was something 
that would very hardly be accepted by anyone, as LLM did lots of stupid
changes that are easily recognized as bad merge material. The final result was
also bad enough. So, for now, it is still easy to identify pure LLM generated
content.

> >>- There are many first-time contributors coming in with LLM-generated
> >>  patches.  At times, I could swear that every one of them is focused on
> >>  documentation typos, but the truth of the matter is that they are
> >>  reaching into subsystems all over the kernel.  We have some brand-new
> >>  contributors making significant changes to dozens of subsystems.  An
> >>  experienced developer would be hard-put to truly understand what those
> >>  changes are doing; a newcomer is unlikely to have that understanding,
> >>  and is unlikely to be around to fix eventual problems.
> >>
> >>  Our maintainers are not scaling to handle this new flood, and I fear we
> >>  are going to see some unfortunate things merged.  One LLM-driven newcomer
> >>  recently nearly succeeded in establishing himself as the maintainer of
> >>  lib/.  How do we hold the line against this stuff while remaining open to
> >>  new developers?  
> >
> > Shouldn't it be a merits question rather than a tools question?
> >
> > If the commits are correct, does it matter if they were written with
> > an LLM? 

It does if the author doesn't understand the code and can't maintain
it without LLM. The bigger issue here is actually to allow people that
doesn't know how to code himself to become a maintainer. 

> > we can insist more on supplying tests and demonstrating
> > correctness, something we seem to be doing quite rarely right now.  

Perhaps we may need to have some interaction with the developers before
letting them to become new maintainers. This may allow checking if the
guy knows what he's doing or if he is only the man-in-the-middle.

> It's definitely a merit question.  But we're not always all that good at
> determining whether a commit is correct, and we depend a lot on the
> contributor understanding their work and being around if something goes
> wrong with it.  That is part of "merit" too.  How confident are we of
> that merit when a brand-new developer makes significant changes to a
> dozen or more unrelated subsystems?

If a brand-new developer is touching lots of unrelated subsystems,
there is a high chance that it is vibe-coding.

> 
> >>- Our process is becoming increasingly dependent on proprietary tools.  We
> >>  have done that before and, in 2005, it went pretty badly for us - and
> >>  could have been worse.  How do we prepare for the inevitable rugpull?  I
> >>  raised this last year, and it was largely brushed off, but I still think
> >>  it's something we should be concerned about.  
> >
> > Are we dependent on them, or do we just find them very useful? If
> > Claude/Codex/etc goes away next month, will it stall any of our processes?
> >
> > We have AI reviews, we have many AI tools that help both authors and
> > maintainers, but I don't think that any of them play an integral part of our
> > process.  
> 
> The related discussions have featured a number of maintainers talking
> about how much time Sashiko has saved them.  I believe them.  How long
> will it take until nobody does that level of patch review anymore?  What
> will we do when the current round of corporate generosity ends and that
> tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
> like a possibility we should keep in mind.

This is a serious concern. It sounds risky to rely on that, as there's
no free lunch. We need to rely on something that can be managed in
an affordable way, prioritizing models that can run on affortable GPUs
and are open source.

Thanks,
Mauro

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Bart Van Assche]

On 7/16/26 11:36 AM, Jonathan Corbet wrote:
> What will we do when the current round of corporate generosity ends
> and that tool goes away?  Maybe I'm worrying too much, but this does 
> seem, to me, like a possibility we should keep in mind.

My understanding is that Sashiko is open source and also that it
supports multiple LLMs. I do not know whether it supports open weight
LLMs. Roman, please correct me if I got anything wrong.

Bart.

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Liam R. Howlett]

On 26/07/16 12:36PM, Jonathan Corbet wrote:
> Sasha Levin <sashal@kernel.org> writes:
> 
> > On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
> >>The use of LLMs in the development process appears to be a clear theme for
> >>the upcoming summit.  On top of what others have already suggested, I think
> >>we may want to consider these questions:
> >>
> >>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
> >>  put something more generic?  I *think* that this thread:
> >>
> >>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
> >>
> >>  reached a consensus that "Assisted-by: LLM" was better than what we
> >>  require now, but it might be good to ratify that in this setting.
> >
> > So originally I've added the full name of the tool and LLM because there was
> > interest in a later audit of the tools to determine how useful (or useless)
> > some of the tools are.
> >
> > If those folks aren't interested in doing so anymore, then sure - we can drop
> > it.
> >
> > But... I find it difficult to see the point of having the tag if we do that.
> 
> Folks like Greg have, in the recent past, said that it is useful even
> without specific product-name information:
> 
>   https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/
> 

There are a few classes of LLM users, but as more and more people are
using LLM, the usefulness of this tag is converging on zero.  We seem to
have three classes of LLM users.

We have people leaning hard on LLMs to push more code, but are known
developers.  The uses of an LLM can be replaced by using an RFC tag for
things that _really_ should be looked at by others prior to acceptance.
That is, if they aren't using RFC already.

We have people using LLMs for writing tests or reviewing code.  A tag
here is not useful as it seems a false sense of security for reviewers
and they may skip it. The LLMs are finding off-by-ones, but the larger
ideas are usually sound and the test cases are actually not all bad.

> >>- There are many first-time contributors coming in with LLM-generated
> >>  patches.  At times, I could swear that every one of them is focused on
> >>  documentation typos, but the truth of the matter is that they are
> >>  reaching into subsystems all over the kernel.  We have some brand-new
> >>  contributors making significant changes to dozens of subsystems.  An
> >>  experienced developer would be hard-put to truly understand what those
> >>  changes are doing; a newcomer is unlikely to have that understanding,
> >>  and is unlikely to be around to fix eventual problems.
> >>
> >>  Our maintainers are not scaling to handle this new flood, and I fear we
> >>  are going to see some unfortunate things merged.  One LLM-driven newcomer
> >>  recently nearly succeeded in establishing himself as the maintainer of
> >>  lib/.  How do we hold the line against this stuff while remaining open to
> >>  new developers?
> >
> > Shouldn't it be a merits question rather than a tools question?
> >
> > If the commits are correct, does it matter if they were written with
> > an LLM? we can insist more on supplying tests and demonstrating
> > correctness, something we seem to be doing quite rarely right now.

People who don't know what they are doing, cannot write tests that cover
the code they are changing.  They don't know what to ask the LLM to do.

Fundamentally, we've given some people a tool that stretches well
outside what they know, so requesting more testing will not result in
valid tests.  You end up writing things like "can you please ask your
LLM to <task>", or more likely something they can copy/paste into it
because they're saying they did it alone.

Half the time you tell them why it won't/doesn't work and they come back
with arguments from an LLM as to why you are wrong.

Also, they'll respin the reviewed patches within minutes, and that can
cost you hours to validate if it/they are not acceptable patch(es).

I've honestly thought about a rule where someone can no longer have
patches accepted again until the next release as they have exceeded a
threshold of time wastage.  (A nack merit?)

> 
> It's definitely a merit question.  But we're not always all that good at
> determining whether a commit is correct, and we depend a lot on the
> contributor understanding their work and being around if something goes
> wrong with it.  That is part of "merit" too.  How confident are we of
> that merit when a brand-new developer makes significant changes to a
> dozen or more unrelated subsystems?

The last class of users..

We have people writing patch sets across many subsystems and/or first
time people rewriting entire sections of the kernel to 'fix' things.

Some of these people are clearly passing off LLM work as their own,
without any LLM tag.  I am at a loss on how to deal with these.  Either
they are encouraged to try over and over, or they blow up at the
suggesting this is LLM and/or a NACK.  Neither method is good and nether
reduces the flow of bad code.

In any case, the tag is useless in this case because it's not going to
be used regardless of what we do.

So on Greg's note that having an LLM tag is a signal,  I question the
SNR now and if the signal is the same indicator across all patches.

> 
> >>- Our process is becoming increasingly dependent on proprietary tools.  We
> >>  have done that before and, in 2005, it went pretty badly for us - and
> >>  could have been worse.  How do we prepare for the inevitable rugpull?  I
> >>  raised this last year, and it was largely brushed off, but I still think
> >>  it's something we should be concerned about.
> >
> > Are we dependent on them, or do we just find them very useful? If
> > Claude/Codex/etc goes away next month, will it stall any of our processes?
> >
> > We have AI reviews, we have many AI tools that help both authors and
> > maintainers, but I don't think that any of them play an integral part of our
> > process.
> 
> The related discussions have featured a number of maintainers talking
> about how much time Sashiko has saved them.  I believe them.  How long
> will it take until nobody does that level of patch review anymore?  What
> will we do when the current round of corporate generosity ends and that
> tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
> like a possibility we should keep in mind.
> 

Agreed.  I think we are already dependent enough on them to have a
visible impact on throughput.  That's going to increase as models become
better.  When the products shift from market capture to monetization,
we're going to have a dip in productivity and quality, at best.

Thanks,
Liam

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Laurent Pinchart]

Hi Sasha,

On Thu, Jul 16, 2026 at 12:24:45PM -0400, Sasha Levin wrote:
> On Thu, Jul 16, 2026 at 05:08:40PM +0100, Mark Brown wrote:
> >On Thu, Jul 16, 2026 at 11:28:25AM -0400, Sasha Levin wrote:
> >> On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
> >
> >> > - There are many first-time contributors coming in with LLM-generated
> >> >  patches.  At times, I could swear that every one of them is focused on
> >
> >> >  Our maintainers are not scaling to handle this new flood, and I fear we
> >> >  are going to see some unfortunate things merged.  One LLM-driven newcomer
> >> >  recently nearly succeeded in establishing himself as the maintainer of
> >> >  lib/.  How do we hold the line against this stuff while remaining open to
> >> >  new developers?
> >
> >> Shouldn't it be a merits question rather than a tools question?
> >
> >> If the commits are correct, does it matter if they were written with an LLM? we
> >> can insist more on supplying tests and demonstrating correctness, something we
> >> seem to be doing quite rarely right now.
> >
> > The issue (which a number of projects are facing) is as much one of
> > volume as anything else, the code generation machines are enabling the
> > generation and submision of volumes of code where things were previously
> > constrained by human factors.  It can turn into a bit of a DoS.  I don't
> > have any particularly bright ideas here but it's definitely a thing.
> 
> Sure, we're seeing quite the increase in patch submissions, but I'm trying to
> argue that the issue isn't a new one: lack of maintainers, trusted reviewers,
> and maintainer burnout has been a topic at each kernel summit for as long as I
> can remember. AI just kicks it up a notch.
> 
> My concern is that if we focus on the AI aspect, we still won't be solving the
> underlying issue.
> 
> I'm hoping we can figure out how to get maintainers great tooling, testing, and
> community, rather than figuring out how to block a developer who uses LLM.
> Maybe AI would actually be a great catalyst for that as well?

Didn't you argue in another part of this thread that we're in no danger
of being depending on AI for our processes ? I see a contradiction here.

-- 
Regards,

Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[James Bottomley]

On Thu, 2026-07-16 at 13:05 -0700, Bart Van Assche wrote:
> 
> On 7/16/26 11:36 AM, Jonathan Corbet wrote:
> > What will we do when the current round of corporate generosity ends
> > and that tool goes away?  Maybe I'm worrying too much, but this
> > does seem, to me, like a possibility we should keep in mind.
> 
> My understanding is that Sashiko is open source and also that it
> supports multiple LLMs. I do not know whether it supports open weight
> LLMs. Roman, please correct me if I got anything wrong.

The corporate generosity isn't the code, it's the free tokens required
to run it on the LLM.  If that free supply dries up, we'll have the
code but won't be able to afford to run it.

Regards,

James

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Theodore Tso]

On Thu, Jul 16, 2026 at 12:36:53PM -0500, Jonathan Corbet wrote:
> The related discussions have featured a number of maintainers talking
> about how much time Sashiko has saved them.  I believe them.  How long
> will it take until nobody does that level of patch review anymore?  What
> will we do when the current round of corporate generosity ends and that
> tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
> like a possibility we should keep in mind.

Sashiko finds issues that human reviewers wouldn't necessarily notice.
Before Sashiko, at least for ext4, I'd find those sorts of issues by
running 24 VM hours worth of fstests, and rely on that testing to find
problems that I might miss when doing the initial patch review.  Could
I have found it by spending 3 times as much time looking at each
commit, and thinking deeply?  Sure.  But I don't have the time for
that, so I've *already* relied on Google contributing roughly two
dollars of VM time for each 24 hour regression test run.  Sashiko
might be a bit more expensive on a per-patch basis, but just as I
never viewed fstests as a replacement for human-level review, I don't
think Sashiko is complete substitute human review.

We still need experienced human reviewers to ask whether the fix is
being done in the right place, or whether the right solution is to
*remove* code as opposed to *adding* code, etc.  This is critical if
we want the code to be maintainable in the long-term.  I agree that if
reviewers stop doing this, we would be in a world of hurt --- but that
can happen if people were to start relying on kunit tests passing as a
substitute for code review.

						- Ted

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Theodore Tso]

On Thu, Jul 16, 2026 at 09:53:42PM -0500, Mauro Carvalho Chehab wrote:
> > What
> > will we do when the current round of corporate generosity ends and that
> > tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
> > like a possibility we should keep in mind.
> 
> This is a serious concern. It sounds risky to rely on that, as there's
> no free lunch. We need to rely on something that can be managed in
> an affordable way, prioritizing models that can run on affortable GPUs
> and are open source.

This gets tricky.  We can divide ML models into a couple of
different classes:

     1. Those that can fit on a mobile phone
     2. Those that can fit on low-end developer machine (16GB-32GB
        unified memory, or 16GB of VRAM in your GPU)
     3. Those that fit in High-end developer machines (128GB unified
        memory, such as could be found in a M5 Max Macbook Pro, a DGX
        Spark, or an AMD Strix Halo)
     4. Those that fit into one or more Enterprise servers with 8 H100
        GPU's --- that is, frontier models.

Machines in category 3 run about $4k (on the low-end, without a
monitor) and go up from there.  About six weeks ago, I invested in a
M5 Max Macbook Pro with 128GB, and it set me back $6,214 USD
(including tax).  When Apple increased their prices due to the
DRAMpocalypse, for the first time, I've seen a computer *appreciate*
in value after being purchased --- by $1,400 USD.  :-)   So questions of
access equity is already an issue with machines in this category.

Machines in category 4 run around $400,000 each.  (Of course, after
the dot.COM bubble implosion, Sunfire E10K's that startups paid
$100,000 ended up selling for pennies on the dollar.  So after a
Neocloud company go out of business, maybe thse machines will be
affordable by individual developers.  However, even then your partner
might not be enthusiastic about the heat and sound from one of these
data center servers being run in your office or living room --- not to
mention the electricity bill.  :-)

Now, a H100 has 80 GB of High Bandwidth Memory (HBM) which has a
bandwidth of 2 TB/s.  So a server with 8 H100's has a 640 GB of HBM
and an aggregate bandwidth of 16 TB/s.  In contrast, a M5 Max with
128 GB and a 40-core GPU has a memory bandwidth of 614 GB/s.  (A
normal M5 Macbook Pro has 153 GB/s memory bandwidth and maxes out at
32GB.)

Running the 671 billion parameter Deepseek R1 model at full precision
requires 1.5TB of VRAM --- so two of these 8x H100 servers.  Of could
try to run them using quantization techniques, by collapsing each
parameter from 16 bits to 4 bits, or even 1 bit to reduce the size of
the ML rig required.  However, you lose a lot of accuracy when you do
that, and when models are much more prone to hallucinate when you use
the more aggressive levels of quantization.

So it's one say to say, we should figure out how to try to run Sashiko
on a local LLM, using open-weight models.  But it's going to be a lot
easier to propose such a thing than to actually do it.

What we *might* be able to try doing is to take an open-weight model
that can fit on a 128GB machine, and then fine-tuning it by feeding it
several years of LKML archives which we convniently have in public
inbox format.  This might allow us to create a specialized model which
is optimized for the Linux kernel, and it would be interesting to see
how this compares with a general frontier model.

But even if we did that, it use would be limited to those people who
can afford one of these 128GB unified memory machines or can otherwise
get access to one of these machines.

Cheers,

					- Ted
				

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Mauro Carvalho Chehab]

On Thu, 16 Jul 2026 19:59:02 -0400
"Theodore Tso" <tytso@mit.edu> wrote:

> On Thu, Jul 16, 2026 at 09:53:42PM -0500, Mauro Carvalho Chehab wrote:
> > > What
> > > will we do when the current round of corporate generosity ends and that
> > > tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
> > > like a possibility we should keep in mind.  
> > 
> > This is a serious concern. It sounds risky to rely on that, as there's
> > no free lunch. We need to rely on something that can be managed in
> > an affordable way, prioritizing models that can run on affortable GPUs
> > and are open source.  
> 
> This gets tricky.  We can divide ML models into a couple of
> different classes:
> 
>      1. Those that can fit on a mobile phone
>      2. Those that can fit on low-end developer machine (16GB-32GB
>         unified memory, or 16GB of VRAM in your GPU)
>      3. Those that fit in High-end developer machines (128GB unified
>         memory, such as could be found in a M5 Max Macbook Pro, a DGX
>         Spark, or an AMD Strix Halo)
>      4. Those that fit into one or more Enterprise servers with 8 H100
>         GPU's --- that is, frontier models.
> 
> Machines in category 3 run about $4k (on the low-end, without a
> monitor) and go up from there.  About six weeks ago, I invested in a
> M5 Max Macbook Pro with 128GB, and it set me back $6,214 USD
> (including tax).  When Apple increased their prices due to the
> DRAMpocalypse, for the first time, I've seen a computer *appreciate*
> in value after being purchased --- by $1,400 USD.  :-)   So questions of
> access equity is already an issue with machines in this category.

I'd say the best would be to aim on (3) and (4). Not as powerful
as H100 GPUs, but it may end work.

> Machines in category 4 run around $400,000 each.  (Of course, after
> the dot.COM bubble implosion, Sunfire E10K's that startups paid
> $100,000 ended up selling for pennies on the dollar.  So after a
> Neocloud company go out of business, maybe thse machines will be
> affordable by individual developers.  However, even then your partner
> might not be enthusiastic about the heat and sound from one of these
> data center servers being run in your office or living room --- not to
> mention the electricity bill.  :-)

Those are really noisy. I don't think it is realistic to use it.
Maybe there is an alternative, but I've no idea about how it
actually works: having multiple machines sharing the same model.
I heard some people using DGX Spark and AMD Strix Halo on such
configurations, but I suspect that performance would seriously
drop.

> Now, a H100 has 80 GB of High Bandwidth Memory (HBM) which has a
> bandwidth of 2 TB/s.  So a server with 8 H100's has a 640 GB of HBM
> and an aggregate bandwidth of 16 TB/s.  In contrast, a M5 Max with
> 128 GB and a 40-core GPU has a memory bandwidth of 614 GB/s.  (A
> normal M5 Macbook Pro has 153 GB/s memory bandwidth and maxes out at
> 32GB.)
> 
> Running the 671 billion parameter Deepseek R1 model at full precision
> requires 1.5TB of VRAM --- so two of these 8x H100 servers.  Of could
> try to run them using quantization techniques, by collapsing each
> parameter from 16 bits to 4 bits, or even 1 bit to reduce the size of
> the ML rig required.  However, you lose a lot of accuracy when you do
> that, and when models are much more prone to hallucinate when you use
> the more aggressive levels of quantization.

There are kv-algorithms that provide a good compromise, like turbo-quant.
the precision is still good with 4 or 3 bits.

> So it's one say to say, we should figure out how to try to run Sashiko
> on a local LLM, using open-weight models.  But it's going to be a lot
> easier to propose such a thing than to actually do it.

The main point is: do we really need 671B parameters? Those models
speak a lot of different languages, have medical databases, and a lot
of other random knowledge that are useless for kernel development.

I've been playing for a while with qwen 3.6 with 24KB context size,
36B parameters (3B activated), 4bits kv quantization and it does produce
some decent results. The main limitation is the context size: it is
probably not big enough to test big files (*)

(*) my GPU has 16GB and it is not dedicated to LLM - still, it does
    present results on a reasonable time (a couple of minutes) and
    with decent precision.

Sure, while we have free tokens for sashiko, we can afford using
bigger models, but at the same time we should invest some effort
to make it viable on smaller models as well.

> What we *might* be able to try doing is to take an open-weight model
> that can fit on a 128GB machine, and then fine-tuning it by feeding it
> several years of LKML archives which we convniently have in public
> inbox format.  This might allow us to create a specialized model which
> is optimized for the Linux kernel, and it would be interesting to see
> how this compares with a general frontier model.
> 
> But even if we did that, it use would be limited to those people who
> can afford one of these 128GB unified memory machines or can otherwise
> get access to one of these machines.

I think we should aim on training an open-wight model up to 36B parameters
with 3-4B parameters activated. Those will run easily on 64B unified 
memory even with a big context and may still work on machines with
16GB or with 32GB VRAM GPU (with partial CPU offload - specially
with 16GB).

Thanks,
Mauro

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Theodore Tso]

On Fri, Jul 17, 2026 at 02:58:12AM -0500, Mauro Carvalho Chehab wrote:
> 
> The main point is: do we really need 671B parameters? Those models
> speak a lot of different languages, have medical databases, and a lot
> of other random knowledge that are useless for kernel development.

Fair; but I do think we need to fine-tune it with a lot LKML text so
that it has the knowledge that we actually need for kernel development
before I'd trust the smaller models.

> I've been playing for a while with qwen 3.6 with 24KB context size,
> 36B parameters (3B activated), 4bits kv quantization and it does produce
> some decent results. The main limitation is the context size: it is
> probably not big enough to test big files (*)

I've been playing with qwen3-next with 256k context context size, 80B
parameters (3B activated), with 8bit quantization, but I haven't been
willing to trust it with generating kernel code.  I have experimenting
to see how it compares with Gemini 3.1 when creating a python script
to send e-mail[1] or creating a bash completion script[2] for my
fstests test appliance.

[1] https://github.com/tytso/xfstests-bld/commit/dfadb2014da446ecb967de51904ee531f7be8bd5
[2] https://github.com/tytso/xfstests-bld/commit/dfadb2014da446ecb967de51904ee531f7be8bd5

However, from Roman tells me, Sashiko is running muliple LLM passes
using a frontier model for each commit review.  So what Sashiko does
is quite a bit more complicated than a series of prompts such as:

   Create a python program which submits an e-mail message using the
   Submission Port (port 587), It should enable encryption using
   STARTTLS and it should obtain the username and password from a
   config.ini file.  Model the python program using the send-mail.py
   in the sandbox directory.  It should support the same command-line
   options but instead of sending the e-mail using sendgrid, it should
   send the e-mail using the Submission protocol.

   Please add pydoc documentation to send-mail-smtp.py.

   Please enhance the program you just created (send-mail-smtp.py) to
   support specifying a path to a certificate file in the
   configuration file in case the user doesn't want to use the system
   provided top-level trusted certificates.

   Please add support for a configuration file parameter which
   specifies whether TLS should be mandatory, optional, or disabled.
   Update the pydoc documentation as necessary.

   Please integrate the functionality found in send-mail.py into
   send-mail-smtp.py.  Instead of getting the Sendgrid API key from an
   environment variable, change it to obtain the Sendgrid API key from
   the configuration file.  If the Sendgrid API key is specified, use
   sendgrid instead of the SMTP submission protocol.  Update the pydoc
   documentation strings.

.... which does work pretty well even on less capable models that I
can run locally.

I guess we could try running Sashiko using ollama-mlx on a Macbook
with 128GB, and see how it works, but my assumption is that the answer
is "not well" --- which is why I really want to look at fine-tuning
one of these smaller models first.

Cheers,

						- Ted

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Mauro Carvalho Chehab]

On Thu, 16 Jul 2026 22:27:54 -0400
"Theodore Tso" <tytso@mit.edu> wrote:

> On Fri, Jul 17, 2026 at 02:58:12AM -0500, Mauro Carvalho Chehab wrote:
> > 
> > The main point is: do we really need 671B parameters? Those models
> > speak a lot of different languages, have medical databases, and a lot
> > of other random knowledge that are useless for kernel development.  
> 
> Fair; but I do think we need to fine-tune it with a lot LKML text so
> that it has the knowledge that we actually need for kernel development
> before I'd trust the smaller models.
> 
> > I've been playing for a while with qwen 3.6 with 24KB context size,
> > 36B parameters (3B activated), 4bits kv quantization and it does produce
> > some decent results. The main limitation is the context size: it is
> > probably not big enough to test big files (*)  
> 
> I've been playing with qwen3-next with 256k context context size, 80B
> parameters (3B activated), with 8bit quantization, but I haven't been
> willing to trust it with generating kernel code.  I have experimenting
> to see how it compares with Gemini 3.1 when creating a python script
> to send e-mail[1] or creating a bash completion script[2] for my
> fstests test appliance.

Most of my tests are also to generate ancillary python scripts too.
I did some tests using it and using chatgpt and deepseek (using a free
account). On my tests, qwen3.6 code (36B, 3B activated) had similar 
quality.

As we're aiming on patch review, we don't need a model capable of
generating kernel code. Instead, we're aiming on one that helps to
review it. A well trained model using lore may end giving similar
results.

As a quality criteria, I'd say if the simpler model would have maybe
80%-90% quality when compared with using a frontier model, it sounds
worth having it, not only for people to run locally but also as a
continuity plan if/when we end running out of free passes to run it
on server-grade GPU hardware.

> [1] https://github.com/tytso/xfstests-bld/commit/dfadb2014da446ecb967de51904ee531f7be8bd5
> [2] https://github.com/tytso/xfstests-bld/commit/dfadb2014da446ecb967de51904ee531f7be8bd5
> 
> However, from Roman tells me, Sashiko is running muliple LLM passes
> using a frontier model for each commit review.  So what Sashiko does
> is quite a bit more complicated than a series of prompts such as:
> 
>    Create a python program which submits an e-mail message using the
>    Submission Port (port 587), It should enable encryption using
>    STARTTLS and it should obtain the username and password from a
>    config.ini file.  Model the python program using the send-mail.py
>    in the sandbox directory.  It should support the same command-line
>    options but instead of sending the e-mail using sendgrid, it should
>    send the e-mail using the Submission protocol.
> 
>    Please add pydoc documentation to send-mail-smtp.py.
> 
>    Please enhance the program you just created (send-mail-smtp.py) to
>    support specifying a path to a certificate file in the
>    configuration file in case the user doesn't want to use the system
>    provided top-level trusted certificates.
> 
>    Please add support for a configuration file parameter which
>    specifies whether TLS should be mandatory, optional, or disabled.
>    Update the pydoc documentation as necessary.
> 
>    Please integrate the functionality found in send-mail.py into
>    send-mail-smtp.py.  Instead of getting the Sendgrid API key from an
>    environment variable, change it to obtain the Sendgrid API key from
>    the configuration file.  If the Sendgrid API key is specified, use
>    sendgrid instead of the SMTP submission protocol.  Update the pydoc
>    documentation strings.
> 
> .... which does work pretty well even on less capable models that I
> can run locally.
> 
> I guess we could try running Sashiko using ollama-mlx on a Macbook
> with 128GB, and see how it works, but my assumption is that the answer
> is "not well" --- which is why I really want to look at fine-tuning
> one of these smaller models first.

I agree with you: without distilling a smaller model, it may not work well. 
However, frontier models may spend a lot more tokens than small models 
for the same prompt, due to mult-step reasoning and the huge amount of
parameters, so we could have some surprise here. Sounds worth trying it.

Thanks,
Mauro

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Laurent Pinchart]

Hi Liam,

On Thu, Jul 16, 2026 at 04:23:19PM -0400, Liam R. Howlett wrote:
> On 26/07/16 12:36PM, Jonathan Corbet wrote:
> > Sasha Levin writes:
> > > On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
> > >>The use of LLMs in the development process appears to be a clear theme for
> > >>the upcoming summit.  On top of what others have already suggested, I think
> > >>we may want to consider these questions:
> > >>
> > >>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
> > >>  put something more generic?  I *think* that this thread:
> > >>
> > >>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
> > >>
> > >>  reached a consensus that "Assisted-by: LLM" was better than what we
> > >>  require now, but it might be good to ratify that in this setting.
> > >
> > > So originally I've added the full name of the tool and LLM because there was
> > > interest in a later audit of the tools to determine how useful (or useless)
> > > some of the tools are.
> > >
> > > If those folks aren't interested in doing so anymore, then sure - we can drop
> > > it.
> > >
> > > But... I find it difficult to see the point of having the tag if we do that.
> > 
> > Folks like Greg have, in the recent past, said that it is useful even
> > without specific product-name information:
> > 
> >   https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/
> 
> There are a few classes of LLM users, but as more and more people are
> using LLM, the usefulness of this tag is converging on zero.  We seem to
> have three classes of LLM users.
> 
> We have people leaning hard on LLMs to push more code, but are known
> developers.  The uses of an LLM can be replaced by using an RFC tag for
> things that _really_ should be looked at by others prior to acceptance.
> That is, if they aren't using RFC already.
> 
> We have people using LLMs for writing tests or reviewing code.  A tag
> here is not useful as it seems a false sense of security for reviewers
> and they may skip it. The LLMs are finding off-by-ones, but the larger
> ideas are usually sound and the test cases are actually not all bad.

A clarification here: multiple people have expressed that they find the
tag useful to guide their reviews, not because it tells them they can be
less cautious, but because they want to be more cautious, or keep an eye
open for different patterns of issues.

There's also been a proposal to replace the model/agent name in the tag
with information about how LLMs were used. Among the people who find the
tag useful, there seems to be a consensus that type of usage is the
important information.

> > >>- There are many first-time contributors coming in with LLM-generated
> > >>  patches.  At times, I could swear that every one of them is focused on
> > >>  documentation typos, but the truth of the matter is that they are
> > >>  reaching into subsystems all over the kernel.  We have some brand-new
> > >>  contributors making significant changes to dozens of subsystems.  An
> > >>  experienced developer would be hard-put to truly understand what those
> > >>  changes are doing; a newcomer is unlikely to have that understanding,
> > >>  and is unlikely to be around to fix eventual problems.
> > >>
> > >>  Our maintainers are not scaling to handle this new flood, and I fear we
> > >>  are going to see some unfortunate things merged.  One LLM-driven newcomer
> > >>  recently nearly succeeded in establishing himself as the maintainer of
> > >>  lib/.  How do we hold the line against this stuff while remaining open to
> > >>  new developers?
> > >
> > > Shouldn't it be a merits question rather than a tools question?
> > >
> > > If the commits are correct, does it matter if they were written with
> > > an LLM? we can insist more on supplying tests and demonstrating
> > > correctness, something we seem to be doing quite rarely right now.
> 
> People who don't know what they are doing, cannot write tests that cover
> the code they are changing.  They don't know what to ask the LLM to do.
> 
> Fundamentally, we've given some people a tool that stretches well
> outside what they know, so requesting more testing will not result in
> valid tests.  You end up writing things like "can you please ask your
> LLM to <task>", or more likely something they can copy/paste into it
> because they're saying they did it alone.
> 
> Half the time you tell them why it won't/doesn't work and they come back
> with arguments from an LLM as to why you are wrong.
> 
> Also, they'll respin the reviewed patches within minutes, and that can
> cost you hours to validate if it/they are not acceptable patch(es).
> 
> I've honestly thought about a rule where someone can no longer have
> patches accepted again until the next release as they have exceeded a
> threshold of time wastage.  (A nack merit?)
> 
> > It's definitely a merit question.  But we're not always all that good at
> > determining whether a commit is correct, and we depend a lot on the
> > contributor understanding their work and being around if something goes
> > wrong with it.  That is part of "merit" too.  How confident are we of
> > that merit when a brand-new developer makes significant changes to a
> > dozen or more unrelated subsystems?
> 
> The last class of users..
> 
> We have people writing patch sets across many subsystems and/or first
> time people rewriting entire sections of the kernel to 'fix' things.
> 
> Some of these people are clearly passing off LLM work as their own,
> without any LLM tag.  I am at a loss on how to deal with these.  Either
> they are encouraged to try over and over, or they blow up at the
> suggesting this is LLM and/or a NACK.  Neither method is good and nether
> reduces the flow of bad code.
> 
> In any case, the tag is useless in this case because it's not going to
> be used regardless of what we do.
> 
> So on Greg's note that having an LLM tag is a signal,  I question the
> SNR now and if the signal is the same indicator across all patches.
> 
> > >>- Our process is becoming increasingly dependent on proprietary tools.  We
> > >>  have done that before and, in 2005, it went pretty badly for us - and
> > >>  could have been worse.  How do we prepare for the inevitable rugpull?  I
> > >>  raised this last year, and it was largely brushed off, but I still think
> > >>  it's something we should be concerned about.
> > >
> > > Are we dependent on them, or do we just find them very useful? If
> > > Claude/Codex/etc goes away next month, will it stall any of our processes?
> > >
> > > We have AI reviews, we have many AI tools that help both authors and
> > > maintainers, but I don't think that any of them play an integral part of our
> > > process.
> > 
> > The related discussions have featured a number of maintainers talking
> > about how much time Sashiko has saved them.  I believe them.  How long
> > will it take until nobody does that level of patch review anymore?  What
> > will we do when the current round of corporate generosity ends and that
> > tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
> > like a possibility we should keep in mind.
> > 
> 
> Agreed.  I think we are already dependent enough on them to have a
> visible impact on throughput.  That's going to increase as models become
> better.  When the products shift from market capture to monetization,
> we're going to have a dip in productivity and quality, at best.

-- 
Regards,

Laurent Pinchart

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[James Bottomley]

On Thu, 2026-07-16 at 16:23 -0400, Liam R. Howlett wrote:
> On 26/07/16 12:36PM, Jonathan Corbet wrote:
> > Sasha Levin <sashal@kernel.org> writes:
> > 
> > > On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
> > > > The use of LLMs in the development process appears to be a
> > > > clear theme for the upcoming summit.  On top of what others
> > > > have already suggested, I think we may want to consider these
> > > > questions:
> > > > 
> > > > - Do we want to continue naming specific LLMs in the Assisted-
> > > > by tags, or  put something more generic?  I *think* that this
> > > > thread:
> > > > 
> > > >   
> > > > https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
> > > > 
> > > >  reached a consensus that "Assisted-by: LLM" was better than
> > > > what we require now, but it might be good to ratify that in
> > > > this setting.
> > > 
> > > So originally I've added the full name of the tool and LLM
> > > because there was interest in a later audit of the tools to
> > > determine how useful (or useless) some of the tools are.
> > > 
> > > If those folks aren't interested in doing so anymore, then sure -
> > > we can drop it.
> > > 
> > > But... I find it difficult to see the point of having the tag if
> > > we do that.
> > 
> > Folks like Greg have, in the recent past, said that it is useful
> > even without specific product-name information:
> > 
> >  
> > https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/
> > 
> 
> There are a few classes of LLM users, but as more and more people are
> using LLM, the usefulness of this tag is converging on zero.

It's not just about whether you find it useful, it's also about whether
it has utility to the project history.  Remember the purpose of the
original signed-off-by tag was to track copyright origin in case of
another SCO like allegation.  Given the current US Copyright position
on generative AI

https://www.copyright.gov/newsnet/2025/1060.html

Whether AI is used or not affects the copyright status of the patch. 
Therefore it is a fairly vital piece of information to preserve, even
if the current advice changes over time.

Regards,

James

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Konstantin Ryabitsev]

On Thu, Jul 16, 2026 at 07:59:02PM -0400, Theodore Tso wrote:
> What we *might* be able to try doing is to take an open-weight model
> that can fit on a 128GB machine, and then fine-tuning it by feeding it
> several years of LKML archives which we convniently have in public
> inbox format.  This might allow us to create a specialized model which
> is optimized for the Linux kernel, and it would be interesting to see
> how this compares with a general frontier model.

I think that will require a significant amount of tuning, because I doubt
anyone wants 2.6-era code generated by the LLM. We're also going to have to
consider any patches arriving post-2025 as potentially LLM-written whether
they carry the Assisted-by tag or not.

I'd go so far as to say that we DON'T want to feed unfiltered LKML archives
into the model -- we probably want to lean on the work done by the cregit
folks to identify patch sets that were actually accepted and then work
backwards, creating a subset of LKML that resulted in accepted contributions.

(Not that any other AI companies are bothered with this detail, as they are
scraping everything as fast as they can.)

-K

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Sasha Levin]

On Thu, Jul 16, 2026 at 12:36:53PM -0600, Jonathan Corbet wrote:
>Sasha Levin <sashal@kernel.org> writes:
>
>> On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
>>>The use of LLMs in the development process appears to be a clear theme for
>>>the upcoming summit.  On top of what others have already suggested, I think
>>>we may want to consider these questions:
>>>
>>>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
>>>  put something more generic?  I *think* that this thread:
>>>
>>>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
>>>
>>>  reached a consensus that "Assisted-by: LLM" was better than what we
>>>  require now, but it might be good to ratify that in this setting.
>>
>> So originally I've added the full name of the tool and LLM because there was
>> interest in a later audit of the tools to determine how useful (or useless)
>> some of the tools are.
>>
>> If those folks aren't interested in doing so anymore, then sure - we can drop
>> it.
>>
>> But... I find it difficult to see the point of having the tag if we do that.
>
>Folks like Greg have, in the recent past, said that it is useful even
>without specific product-name information:
>
>  https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/

No disagreement it would help reviews, but there's no need to carry it in the
git history after it's merged, so no reason for it to be a tag I think.

Should we move it to under the scissor line? Or move to something along the
lines of:

	[PATCH AI] abc: zzzz

>>>- There are many first-time contributors coming in with LLM-generated
>>>  patches.  At times, I could swear that every one of them is focused on
>>>  documentation typos, but the truth of the matter is that they are
>>>  reaching into subsystems all over the kernel.  We have some brand-new
>>>  contributors making significant changes to dozens of subsystems.  An
>>>  experienced developer would be hard-put to truly understand what those
>>>  changes are doing; a newcomer is unlikely to have that understanding,
>>>  and is unlikely to be around to fix eventual problems.
>>>
>>>  Our maintainers are not scaling to handle this new flood, and I fear we
>>>  are going to see some unfortunate things merged.  One LLM-driven newcomer
>>>  recently nearly succeeded in establishing himself as the maintainer of
>>>  lib/.  How do we hold the line against this stuff while remaining open to
>>>  new developers?
>>
>> Shouldn't it be a merits question rather than a tools question?
>>
>> If the commits are correct, does it matter if they were written with
>> an LLM? we can insist more on supplying tests and demonstrating
>> correctness, something we seem to be doing quite rarely right now.
>
>It's definitely a merit question.  But we're not always all that good at
>determining whether a commit is correct, and we depend a lot on the
>contributor understanding their work and being around if something goes
>wrong with it.  That is part of "merit" too.  How confident are we of
>that merit when a brand-new developer makes significant changes to a
>dozen or more unrelated subsystems?

Third of authors have only one commit, more than half have 2 or less. I'd argue
that we need to be very good about taking driveby commits with the assumption
that we'll never hear back from the author either way.

>>>- Our process is becoming increasingly dependent on proprietary tools.  We
>>>  have done that before and, in 2005, it went pretty badly for us - and
>>>  could have been worse.  How do we prepare for the inevitable rugpull?  I
>>>  raised this last year, and it was largely brushed off, but I still think
>>>  it's something we should be concerned about.
>>
>> Are we dependent on them, or do we just find them very useful? If
>> Claude/Codex/etc goes away next month, will it stall any of our processes?
>>
>> We have AI reviews, we have many AI tools that help both authors and
>> maintainers, but I don't think that any of them play an integral part of our
>> process.
>
>The related discussions have featured a number of maintainers talking
>about how much time Sashiko has saved them.  I believe them.  How long
>will it take until nobody does that level of patch review anymore?  What
>will we do when the current round of corporate generosity ends and that
>tool goes away?  Maybe I'm worrying too much, but this does seem, to me,
>like a possibility we should keep in mind.

It'll slow the process down, I agree, but it wouldn't stop it altogether. I
would agree it shouldn't become a critical part of our workflow, but right now
it seems to me like this tooling just lives on the periphery of our processes,
and having these tools go away won't actually block the process.

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Konstantin Ryabitsev]

On Fri, Jul 17, 2026 at 09:59:36AM -0400, Sasha Levin wrote:
> > Folks like Greg have, in the recent past, said that it is useful even
> > without specific product-name information:
> > 
> >  https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/
> 
> No disagreement it would help reviews, but there's no need to carry it in the
> git history after it's merged, so no reason for it to be a tag I think.
> 
> Should we move it to under the scissor line? Or move to something along the
> lines of:
> 
> 	[PATCH AI] abc: zzzz

Ew, no. :) The subject line is already super overloaded.

I can suggest putting it as a footer, same as base-commit,
prerequisite-patch-id, etc, e.g.:

| ---
| base-commit: abcd...1234
| change-id: 20260717-great-balls-of-fire-abcd1234
| assisted-by: LLM [planning, tests, codegen, tests]

I can easily put this into b4, and if we do add an AGENTS.md file, this can be
described there as well, so series created by LLMs will be more likely to
automatically carry this footer.

-K

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Sasha Levin]

On Thu, Jul 16, 2026 at 11:38:10PM +0300, Laurent Pinchart wrote:
>Hi Sasha,
>
>On Thu, Jul 16, 2026 at 12:24:45PM -0400, Sasha Levin wrote:
>> On Thu, Jul 16, 2026 at 05:08:40PM +0100, Mark Brown wrote:
>> >On Thu, Jul 16, 2026 at 11:28:25AM -0400, Sasha Levin wrote:
>> >> On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
>> >
>> >> > - There are many first-time contributors coming in with LLM-generated
>> >> >  patches.  At times, I could swear that every one of them is focused on
>> >
>> >> >  Our maintainers are not scaling to handle this new flood, and I fear we
>> >> >  are going to see some unfortunate things merged.  One LLM-driven newcomer
>> >> >  recently nearly succeeded in establishing himself as the maintainer of
>> >> >  lib/.  How do we hold the line against this stuff while remaining open to
>> >> >  new developers?
>> >
>> >> Shouldn't it be a merits question rather than a tools question?
>> >
>> >> If the commits are correct, does it matter if they were written with an LLM? we
>> >> can insist more on supplying tests and demonstrating correctness, something we
>> >> seem to be doing quite rarely right now.
>> >
>> > The issue (which a number of projects are facing) is as much one of
>> > volume as anything else, the code generation machines are enabling the
>> > generation and submision of volumes of code where things were previously
>> > constrained by human factors.  It can turn into a bit of a DoS.  I don't
>> > have any particularly bright ideas here but it's definitely a thing.
>>
>> Sure, we're seeing quite the increase in patch submissions, but I'm trying to
>> argue that the issue isn't a new one: lack of maintainers, trusted reviewers,
>> and maintainer burnout has been a topic at each kernel summit for as long as I
>> can remember. AI just kicks it up a notch.
>>
>> My concern is that if we focus on the AI aspect, we still won't be solving the
>> underlying issue.
>>
>> I'm hoping we can figure out how to get maintainers great tooling, testing, and
>> community, rather than figuring out how to block a developer who uses LLM.
>> Maybe AI would actually be a great catalyst for that as well?
>
>Didn't you argue in another part of this thread that we're in no danger
>of being depending on AI for our processes ? I see a contradiction here.

Hey Laurent,

Not sure I follow here.

My thinking was that trying to improve our processes and tooling has been a
topic for the past decade or two. One of the times we discussed it was the 2019
maintainer's summit (https://lwn.net/Articles/799134/) where we decided to
create the workflows@ mailing list to share our tooling and workflows. Not much
of that has been happening :)

In the past year or two I was able to rewrite most of my ugly scripts, automate
so many of the processes I used to do manually, and just improve so many
quality of life items thanks to AI. Look even at the CVE process that was
created last year: so much of the infrastructure used to drive it was created
with AI.

Now, if AI suddenly goes away tomorrow it'll suck for me, but I'll just go back
to writing my tools manually like I did before. I don't think that I somehow
became "dependant" on it.

-- 
Thanks,
Sasha

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Andrew Lunn]

> I'd go so far as to say that we DON'T want to feed unfiltered LKML archives
> into the model -- we probably want to lean on the work done by the cregit
> folks to identify patch sets that were actually accepted and then work
> backwards, creating a subset of LKML that resulted in accepted contributions.

I'm not an LLM person....

Is there no value in looking at patches which got rejected, and why
they got rejected, as a template what not to do?

As a reviewer, most of what i do is tell people what they got wrong,
please change it to do it this way instead. An LLM that can parrot me
when it sees the same errors would be useful, when it is doing
reviews.

    Andrew

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1942 bytes --]

On Thu, Jul 16, 2026 at 12:24:45PM -0400, Sasha Levin wrote:
> On Thu, Jul 16, 2026 at 05:08:40PM +0100, Mark Brown wrote:

> > The issue (which a number of projects are facing) is as much one of
> > volume as anything else, the code generation machines are enabling the
> > generation and submision of volumes of code where things were previously
> > constrained by human factors.  It can turn into a bit of a DoS.  I don't
> > have any particularly bright ideas here but it's definitely a thing.

> Sure, we're seeing quite the increase in patch submissions, but I'm trying to
> argue that the issue isn't a new one: lack of maintainers, trusted reviewers,
> and maintainer burnout has been a topic at each kernel summit for as long as I
> can remember. AI just kicks it up a notch.

> My concern is that if we focus on the AI aspect, we still won't be solving the
> underlying issue.

My experience is that the AI stuff is qualtatively quite different to
the general pattern there, the human factors are a big part of it as is
the fact that unlike other tooling it's not doing anything regular or
predictable so you can't develop confidence in the tooling in the same
way you might otherwise.  This all makes the back pressure that helps
mitigate things less effective.

> I'm hoping we can figure out how to get maintainers great tooling, testing, and
> community, rather than figuring out how to block a developer who uses LLM.
> Maybe AI would actually be a great catalyst for that as well?

There's a money question there of course, I note that my own out of
pocket expenses for non-LLM tooling are non-zero and there's an
economic concern among the various concerns about the LLM stuff.

I do also think there's a place for a conversation about trying to get
the people using these tools to do so in a way that's easier to deal
with, a huge portion of the issues people have with them are to do with
externatilities that they create.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Konstantin Ryabitsev]

On Fri, Jul 17, 2026 at 04:24:15PM +0200, Andrew Lunn wrote:
> > I'd go so far as to say that we DON'T want to feed unfiltered LKML archives
> > into the model -- we probably want to lean on the work done by the cregit
> > folks to identify patch sets that were actually accepted and then work
> > backwards, creating a subset of LKML that resulted in accepted contributions.
> 
> I'm not an LLM person....
> 
> Is there no value in looking at patches which got rejected, and why
> they got rejected, as a template what not to do?

There is, but this is part of the "tuning" bit that I said would be needed and
this would require significant amounts of work. First of all, patches would
need to be considered within the context of the entire discussion, not by
themselves. Subsequent series (v1, v2, vN) would need to be grouped together
and consumed within the same context. Series that resulted in no reviews and
no commits will need to be given a special consideration, because we have no
context why they weren't accepted. It's possible that it was great code that
got missed because the maintainer was overloaded, or if it's useless junk that
nobody even bothered to deign with a response.

So, yeah, we have tons of data, but to be useful for training a model, it will
need to be carefully filtered and weighted.

-K

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Andrew Lunn]

On Fri, Jul 17, 2026 at 10:32:28AM -0400, Konstantin Ryabitsev wrote:
> On Fri, Jul 17, 2026 at 04:24:15PM +0200, Andrew Lunn wrote:
> > > I'd go so far as to say that we DON'T want to feed unfiltered LKML archives
> > > into the model -- we probably want to lean on the work done by the cregit
> > > folks to identify patch sets that were actually accepted and then work
> > > backwards, creating a subset of LKML that resulted in accepted contributions.
> > 
> > I'm not an LLM person....
> > 
> > Is there no value in looking at patches which got rejected, and why
> > they got rejected, as a template what not to do?
> 
> There is, but this is part of the "tuning" bit that I said would be needed and
> this would require significant amounts of work.

O.K. So there might be some low hanging fruit. netdev makes use of a
bot reading replies to patches looking for 'pw-bot: <status>' in the
message. If it sees status as 'changes-requested' or 'cr' it drops the
patchset from our CI, because we expect the submitter to make a
change.

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html#updating-patch-status

So these would make good training for the negative side, don't do
this.

	Andrew

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Johannes Weiner]

On Thu, Jul 16, 2026 at 04:23:19PM -0400, Liam R. Howlett wrote:
> So on Greg's note that having an LLM tag is a signal,  I question the
> SNR now and if the signal is the same indicator across all patches.

Yes. The possible range of involvement is massive. The question I
would find more interesting than a binary flag is who was doing what
part of the thinking at each step of creating the patch(es).

You can use agents to draft code, make tests, run experiments, analyze
data, and review for bugs. The human can apply a high level of
direction, scrutiny and steering on each of these steps. Or they can
just not do any of that and still get some kind of result.

Once a workable direction is found, the final result that gets sent to
the list could be a clean-room implementation written by the human, it
could be fully written by an agent, or anything in between.

And finally the human could have reviewed the work end-to-end,
line-by-line; delegated it all to a review agent; or neither.

The process behind a patch with this tag could be anywhere on this
spectrum. And reviewer interpretation of the tag is just as varied.

It poorly communicates what actually occurred. And there is clearly a
stigma attached to it at this point, with the expected consequences,
which further distorts the signal. The latter part might go away if
there was a better protocol to convey the development process.

But I'm not sure it's practical to even try to capture all these
nuances and precise division of labor questions in commit metadata...

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Liam R. Howlett]

On 26/07/17 07:57AM, James Bottomley wrote:
> On Thu, 2026-07-16 at 16:23 -0400, Liam R. Howlett wrote:
> > On 26/07/16 12:36PM, Jonathan Corbet wrote:
> > > Sasha Levin <sashal@kernel.org> writes:
> > > 
> > > > On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
> > > > > The use of LLMs in the development process appears to be a
> > > > > clear theme for the upcoming summit.  On top of what others
> > > > > have already suggested, I think we may want to consider these
> > > > > questions:
> > > > > 
> > > > > - Do we want to continue naming specific LLMs in the Assisted-
> > > > > by tags, or  put something more generic?  I *think* that this
> > > > > thread:
> > > > > 
> > > > >   
> > > > > https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
> > > > > 
> > > > >  reached a consensus that "Assisted-by: LLM" was better than
> > > > > what we require now, but it might be good to ratify that in
> > > > > this setting.
> > > > 
> > > > So originally I've added the full name of the tool and LLM
> > > > because there was interest in a later audit of the tools to
> > > > determine how useful (or useless) some of the tools are.
> > > > 
> > > > If those folks aren't interested in doing so anymore, then sure -
> > > > we can drop it.
> > > > 
> > > > But... I find it difficult to see the point of having the tag if
> > > > we do that.
> > > 
> > > Folks like Greg have, in the recent past, said that it is useful
> > > even without specific product-name information:
> > > 
> > >  
> > > https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/
> > > 
> > 
> > There are a few classes of LLM users, but as more and more people are
> > using LLM, the usefulness of this tag is converging on zero.
> 
> It's not just about whether you find it useful, it's also about whether
> it has utility to the project history.  Remember the purpose of the
> original signed-off-by tag was to track copyright origin in case of
> another SCO like allegation.  Given the current US Copyright position
> on generative AI
> 
> https://www.copyright.gov/newsnet/2025/1060.html
> 
> Whether AI is used or not affects the copyright status of the patch. 
> Therefore it is a fairly vital piece of information to preserve, even
> if the current advice changes over time.
> 

I think this supports the fact that the usefulness of the tag is going
to zero, at least in the current form.. but I'm not a lawyer.

On the mm side of thing, we have sashiko looking at things and getting
pointed to the reports, so that means all mm code is getting inspected
by an AI.  Adding a tag specifying that is useless noise, and certainly
does not affect the copyright according to your link.

Are you thinking that, at some point a specific AI might be ruled a
copyright violation and we will need to audit the commits?

Thanks,
Liam

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Liam R. Howlett]

On 26/07/17 10:49AM, Laurent Pinchart wrote:
> Hi Liam,
> 
> On Thu, Jul 16, 2026 at 04:23:19PM -0400, Liam R. Howlett wrote:
> > On 26/07/16 12:36PM, Jonathan Corbet wrote:
> > > Sasha Levin writes:
> > > > On Thu, Jul 16, 2026 at 09:09:27AM -0600, Jonathan Corbet wrote:
> > > >>The use of LLMs in the development process appears to be a clear theme for
> > > >>the upcoming summit.  On top of what others have already suggested, I think
> > > >>we may want to consider these questions:
> > > >>
> > > >>- Do we want to continue naming specific LLMs in the Assisted-by tags, or
> > > >>  put something more generic?  I *think* that this thread:
> > > >>
> > > >>    https://lore.kernel.org/all/20260701-work-coding-assistants-v1-1-a20a94d1d606@kernel.org/
> > > >>
> > > >>  reached a consensus that "Assisted-by: LLM" was better than what we
> > > >>  require now, but it might be good to ratify that in this setting.
> > > >
> > > > So originally I've added the full name of the tool and LLM because there was
> > > > interest in a later audit of the tools to determine how useful (or useless)
> > > > some of the tools are.
> > > >
> > > > If those folks aren't interested in doing so anymore, then sure - we can drop
> > > > it.
> > > >
> > > > But... I find it difficult to see the point of having the tag if we do that.
> > > 
> > > Folks like Greg have, in the recent past, said that it is useful even
> > > without specific product-name information:
> > > 
> > >   https://lore.kernel.org/all/2026070227-payroll-eradicate-8f66@gregkh/
> > 
> > There are a few classes of LLM users, but as more and more people are
> > using LLM, the usefulness of this tag is converging on zero.  We seem to
> > have three classes of LLM users.
> > 
> > We have people leaning hard on LLMs to push more code, but are known
> > developers.  The uses of an LLM can be replaced by using an RFC tag for
> > things that _really_ should be looked at by others prior to acceptance.
> > That is, if they aren't using RFC already.
> > 
> > We have people using LLMs for writing tests or reviewing code.  A tag
> > here is not useful as it seems a false sense of security for reviewers
> > and they may skip it. The LLMs are finding off-by-ones, but the larger
> > ideas are usually sound and the test cases are actually not all bad.
> 
> A clarification here: multiple people have expressed that they find the
> tag useful to guide their reviews, not because it tells them they can be
> less cautious, but because they want to be more cautious, or keep an eye
> open for different patterns of issues.
> 
> There's also been a proposal to replace the model/agent name in the tag
> with information about how LLMs were used. Among the people who find the
> tag useful, there seems to be a consensus that type of usage is the
> important information.

This would go a long way to make the tag more useful.  The way AI was
used is more interesting than the name and build of the agent used, imo.

Thanks,
Liam

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Liam R. Howlett]

On 26/07/17 04:54PM, Johannes Weiner wrote:
> On Thu, Jul 16, 2026 at 04:23:19PM -0400, Liam R. Howlett wrote:
> > So on Greg's note that having an LLM tag is a signal,  I question the
> > SNR now and if the signal is the same indicator across all patches.
> 
> Yes. The possible range of involvement is massive. The question I
> would find more interesting than a binary flag is who was doing what
> part of the thinking at each step of creating the patch(es).
> 
> You can use agents to draft code, make tests, run experiments, analyze
> data, and review for bugs. The human can apply a high level of
> direction, scrutiny and steering on each of these steps. Or they can
> just not do any of that and still get some kind of result.
> 
> Once a workable direction is found, the final result that gets sent to
> the list could be a clean-room implementation written by the human, it
> could be fully written by an agent, or anything in between.
> 
> And finally the human could have reviewed the work end-to-end,
> line-by-line; delegated it all to a review agent; or neither.
> 
> The process behind a patch with this tag could be anywhere on this
> spectrum. And reviewer interpretation of the tag is just as varied.
> 
> It poorly communicates what actually occurred. And there is clearly a
> stigma attached to it at this point, with the expected consequences,
> which further distorts the signal. The latter part might go away if
> there was a better protocol to convey the development process.
> 
> But I'm not sure it's practical to even try to capture all these
> nuances and precise division of labor questions in commit metadata...

Yeah, well said.

And at that point, why even have a tag?  Maybe something in the cover
letter would be better to explain what went on, but this is hardly what
and why things changed.  And without a standard way of communicating how
the tool was used, then we're back to a signal/noise issue again.

Which, I think is covered by your statement of the 'commit metadata' not
being practical for the task.

To your point of stigma being attached to patches, this is probably why
some people insist LLMs were not used when they clearly were.

Thanks,
Liam

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[James Bottomley]

On Fri, 2026-07-17 at 11:53 -0400, Liam R. Howlett wrote:
> On 26/07/17 07:57AM, James Bottomley wrote:
> > On Thu, 2026-07-16 at 16:23 -0400, Liam R. Howlett wrote:
[...]
> > > There are a few classes of LLM users, but as more and more people
> > > are using LLM, the usefulness of this tag is converging on zero.
> > 
> > It's not just about whether you find it useful, it's also about
> > whether it has utility to the project history.  Remember the
> > purpose of the original signed-off-by tag was to track copyright
> > origin in case of another SCO like allegation.  Given the current
> > US Copyright position on generative AI
> > 
> > https://www.copyright.gov/newsnet/2025/1060.html
> > 
> > Whether AI is used or not affects the copyright status of the
> > patch. Therefore it is a fairly vital piece of information to
> > preserve, even if the current advice changes over time.
> > 
> 
> I think this supports the fact that the usefulness of the tag is
> going to zero, at least in the current form.. but I'm not a lawyer.

From a what use is it to me point of view, possibly.  I'm more looking
at it as being we need a permanent record of this in the git tree.

> On the mm side of thing, we have sashiko looking at things and
> getting pointed to the reports, so that means all mm code is getting
> inspected by an AI.  Adding a tag specifying that is useless noise,
> and certainly does not affect the copyright according to your link.

Agreed, we only really need to know if AI helped write the code, not
really if it helped discover the problem (although giving it a reported
by credit would be fine, especially since 0day keeps prodding for one).

> Are you thinking that, at some point a specific AI might be ruled a
> copyright violation and we will need to audit the commits?

I'm not taking any specific view, I'm just noting that the issue isn't
settled and if the house of cards where everyone funds everyone else's
tokens collapses and AI starts to try to find another business model,
there's a well worn one trying to monetize copyrights ... particularly
if you have deep pockets to buy legislation ...

But the point is that whatever happens (even if nothing does) we'd have
tags in the code base to identify most of the affected code.

Regards,

James

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[Dan Carpenter]

On Fri, Jul 17, 2026 at 02:12:31PM -0400, James Bottomley wrote:
> On Fri, 2026-07-17 at 11:53 -0400, Liam R. Howlett wrote:
> But the point is that whatever happens (even if nothing does) we'd have
> tags in the code base to identify most of the affected code.

The Signed-off-by rules are simple to enforce but it's impossible to
know when a patch is written by AI.  It's definitely a small minority
of patches which are tagged and not "most of the affected code".

regards,
dan carpenter

Re: [MAINTAINERS SUMMIT] Other LLM-related topics - tags, newcomers, etc

[James Bottomley]

On Fri, 2026-07-17 at 21:27 +0300, Dan Carpenter wrote:
> On Fri, Jul 17, 2026 at 02:12:31PM -0400, James Bottomley wrote:
> > On Fri, 2026-07-17 at 11:53 -0400, Liam R. Howlett wrote:
> > But the point is that whatever happens (even if nothing does) we'd
> > have
> > tags in the code base to identify most of the affected code.
> 
> The Signed-off-by rules are simple to enforce

They're not really enforced at all.  It's the legal equivalent of a
representation, it just means I read the DCO and I represent I conform
to what it says.  Externally we have no verification mechanism that the
person signing off actually did this ... although if they're regular
contributors the trust factor is higher, and if they get caught faking
signoffs then the trust factor goes down.

>  but it's impossible to know when a patch is written by AI.  It's
> definitely a small minority of patches which are tagged and not "most
> of the affected code".

That's the point about it being a representation ... we need the
committer to be honest about it.  Although, at least in conference
submissions, we have had some success at employing AI to detect AI
usage.

Regards,

James