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: <aIprj_SFsYv2ABRo@lappy>
Date: Wed, 30 Jul 2025 14:59:27 -0400
From: Sasha Levin <sashal@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Al Viro <viro@...iv.linux.org.uk>, Steven Rostedt <rostedt@...dmis.org>,
	Greg KH <greg@...ah.com>, 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>,
	"Dr. David Alan Gilbert" <linux@...blig.org>
Subject: Re: [PATCH 0/4] Add agent coding assistant configuration to Linux
 kernel

On Wed, Jul 30, 2025 at 07:24:13PM +0100, Lorenzo Stoakes wrote:
>On Wed, Jul 30, 2025 at 02:10:26PM -0400, Sasha Levin wrote:
>> On Wed, Jul 30, 2025 at 06:59:09PM +0100, Al Viro wrote:
>> > On Wed, Jul 30, 2025 at 01:46:47PM -0400, Sasha Levin wrote:
>> >
>> > > Similarily the argument around not trusting the code is equivalent to
>> > > not trusting the person who sent the code in. AI doesn't send patches on
>> > > it's own - humans do. This is basically saying "I didn't even look at
>> > > your patch because I don't trust you".
>> >
>> > One name: Markus Elfring.  Ever tried to reason with that one?  Or Hillf
>> > Danton, for that matter.
>> >
>> > And I absolutely will refuse to take patches from somebody who would
>> > consistently fail to explain why the patch is correct and needed.  Sasha,
>> > this is the elephant in the room: we *ALREADY* get "contributions" that
>> > very clearly stem from "$TOOL says so, what else do you need?" kind of
>> > reasoning and some of that dreck ends up in the tree.  AI will serve as
>> > a force multiplier for those...  persons.
>>
>> This is exactly my argument Al :)
>>
>> You, as a maintainer, should be able to just reject patches without
>> having to provide a technical explanation for each patch you ignore.
>>
>> If someone new comes along and bombards you with AI generated crap and
>> useless review comments, you should be able to just block him and point
>> to something under Documentation/ that will support that decision.
>
>I'm in alignment with Al and your view here FWIW!
>
>Though I do think Steven has a point in that there must be a _good reason_
>that aligns with the community for doing so, and it shouldn't be arbitrary.

I don't disagree with Steve: Ideally there is a technical reason to
block submissions, but as this is a judgement call I'd rather defer it
to the maintainer (usually people don't become maintainers by making bad
decisions :) ).

The tricky part is that this is all subjective... What's "good enough"?

As a compromise, what about allowing a maintainer to block submissions
without having to provide a technical reason, but then offer a path of
escalation with the TAB to mediate between the developer and the
maintainer?

-- 
Thanks,
Sasha