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: <aIpYzg4cI6ELyvYV@gallifrey>
Date: Wed, 30 Jul 2025 17:39:26 +0000
From: "Dr. David Alan Gilbert" <linux@...blig.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, 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

* Steven Rostedt (rostedt@...dmis.org) wrote:
> On Wed, 30 Jul 2025 16:40:39 +0000
> "Dr. David Alan Gilbert" <linux@...blig.org> wrote:
> 
> > * Steven Rostedt (rostedt@...dmis.org) wrote:
> > > On Wed, 30 Jul 2025 16:34:28 +0100
> > > Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> > >   
> > > > > Which looked like someone else (now Cc'd on this thread) took it public,  
> > 
> > (I didn't know of the tab discussion)
> 
> Well, you were not there ;-)
> 
> > > 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.
> > 
> > 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.
> 
> Right. So I believe those that did not want the tag, wanted the statement
> to be under the "---" so that it will not get into the git log. I prefer
> the tag, but I'll be OK with the comment below the "---" as long as it is
> clearly stated that the code was generated by AI.

I think the 'clearly stated' is bound to get messy, especially with
multiple (natural) languages.  A tag doesn't have that ambiguity.
My preference for having it above the --- is to allow later analysis
(does the Foo AI tend to mess up checks for .... ?)
It might also be useful for those other GPL licensed projects that
don't accept AI generated code.

> > 
> >   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?
> 
> Yes, this is one of the controversial issues with having a policy. How much
> does AI have to help you before you must disclose it. I would say basic
> completions shouldn't be an issue. I've had editors where I type "for" it
> then fills in "for (int i = 0; ; i++)". Is that AI? I don't think so.

What happens when it looks at the type you're using and turns it into a
use of a macro like list_for_each()?   I suspect the line is fuzzy.

Personally that doesn't worry me much, but I don't think I can tell others
not to worry about it.

> I'm more concern where you use AI to come up with an algorith. "Hey AI,
> sort this array with a quick-sort routine". And it does so. That should be
> denoted in the change log. Either above or below the '---'.
> 
> > 
> >   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.
> 
> Fixes and changes I don't think require disclosure as long as the human
> looks at that code and figures out that the code needs to change. Now if
> the AI does the fix for you, as in makes the patch, then yeah, you should
> disclose it. But if you manual make the patch after looking at what AI
> pointed you to, then it should be fine.
> 
> > 
> >   d) Either way there needs to be emphasis that the 'Signed-off-by'
> >     is a human declaring it's all legal and checked.
> 
> That should go without saying.

My point is that it needs saying loudly in the docs!

Dave

> -- Steve
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/