linux-kernel - Re: [PATCH 0/4] Add agent coding assistant configuration to Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250730132054.1e710372@gandalf.local.home>
Date: Wed, 30 Jul 2025 13:20:54 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: "Dr. David Alan Gilbert" <linux@...blig.org>, Greg KH <greg@...ah.com>,
 Sasha Levin <sashal@...nel.org>, corbet@....net, linux-doc@...r.kernel.org,
 workflows@...r.kernel.org, josh@...htriplett.org, kees@...nel.org,
 konstantin@...uxfoundation.org, linux-kernel@...r.kernel.org, Linus
 Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 0/4] Add agent coding assistant configuration to Linux
 kernel

On Wed, 30 Jul 2025 18:10:51 +0100
Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:

> > > I guess a statement in submitting-patches.rst would suffice, or should it
> > > be a separate standalone document?  
> >
> > If it's separate I think it needs to have a link from submitting-patches.rst
> > to get people to read it.  
> 
> Absolutely agree.

Sorry for cropping your response about submitting patches, but honestly, I
think it may get more visibility there than in a separate doc. That's
because submitting-patches is one of the most popular documents kernel devs
reference to people submitting patches!

Of course, adding a link as suggested above may fix that too.

> 
> >
> > To summarise some other things that came up between the threads:
> >   a) I think there should be a standard syntax for stating it is
> >      AI written; I'd suggested using a new tag, but others were
> >      arguing on the side of reusing existing tags, which seems OK
> >      if it is done in a standard way and doesn't confuse existing tools.  
> 
> Yes.
> 
> >
> >   b) There's a whole spectrum of:
> >       i) AI wrote the whole patch based on a vague requirement
> >      ii) AI is in the editor and tab completes stuff
> >     iii) AI suggests fixes/changes
> >     which do you care about?  
> 
> I think any AI involvment that results in _changes to the code_ should
> require the tag.

I disagree with this. As I reply, I don't think if you have AI finishing
your for loops and such requires disclosure. As I believe that may soon be
the norm of most folks and then we may get AI storms.

And then, if you have people saying "I don't want any AI patches", does
that mean those that use AI for templates and such will now be forbidden
from submitting to those subsystems?

I would say if AI creates any algorithm for you then it must be disclosed.

> 
> >
> >   c) But then once you get stuff suggesting fixes/changes people were
> >     wondering if you should specify other non-AI tools as well.
> >     That might help reviewers who get bombed by a million patches
> >     from some conventional tool.  

I should add that non-AI tools should always come with a disclaimer that
they were used. For the most part, most submissions that use non-AI tooling
has done this. I just don't think we ever made any formal policy about it.

-- Steve