All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Cc: Theodore Tso <tytso@mit.edu>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Sasha Levin <sashal@kernel.org>,
	corbet@lwn.net, skhan@linuxfoundation.org, rdunlap@infradead.org,
	federico.vaga@vaga.pv.it, apw@canonical.com, joe@perches.com,
	workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Justin Stitt <justinstitt@google.com>,
	Carlos Maiolino <cem@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>,
	Jori Koolstra <jkoolstra@xs4all.nl>,
	Brian Foster <bfoster@redhat.com>,
	Christoph Hellwig <hch@infradead.org>,
	David Disseldorp <ddiss@suse.de>, Mark Brown <broonie@kernel.org>,
	Jani Nikula <jani.nikula@intel.com>, Jens Axboe <axboe@kernel.dk>,
	"David Hildenbrand (Arm)" <david@kernel.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	"Christian Brauner (Amutable)" <brauner@kernel.org>
Subject: Re: [PATCH] docs: remove Assisted-by references
Date: Tue, 20 Oct 2026 01:44:48 +0300	[thread overview]
Message-ID: <20261019224448.GC15441@killaraus.ideasonboard.com> (raw)
In-Reply-To: <as-Dwg8DcEOYMXki@gremlin>

On Wed, Oct 14, 2026 at 02:42:09PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Tue, Oct 13, 2026 at 11:23:53PM -0400, Theodore Tso wrote:
> 
> > I think we're going about this the wrong way.  What we want is high
> > quality contributions.  If they are high quality, who cares if they
> > are AI-generated or not?
> 
> Recently 2 people sent 1,000 patches over 2 hours. Care to check each and
> every patch for 'quality'? :) Only the beginning.

That's the kind of behaviour that should be easy to detect, and I have
absolutely no issue with sending all those patches to /dev/null. This is
script kiddies behaviour, not the work of someone with good intentions.
Ignoring those patches is not "collateral damage".

We could go a step further. There's also an increase in patches from
newcomers who send a few patches only, with the usual signs of not
understanding what they're doing: code changes that give an eerie
feeling, very large comment to code ratios, and commit messages longer
than the three volumes of Lord of the Rings combined. As far as I
understand, those are also the kind of contributions that many
maintainers in this e-mail thread would like to ignore. Perhaps with an
automated reply to tell that the kernel expects submitters to understand
what they're doing and own their code, as this category is less of an
obvious on-purpose DoS attack.

There's some irony there though. I wouldn't be surprised if the
headlines about kernel maintainers loving LLMs made the flood of patches
even worse, and we now have maintainers essentially saying they don't
want to receive most of the LLM-generated patches.

> > If we get a contribution which is sloppy, it could be because the
> 
> Schloppy, not sloppy :) I.e. tells. Turn of phrase, certain 'shapes' in the
> code/commit msgs, newcomer/recently reactivated? Sent a bunch of mails
> across many subsystems? etc.
> 
> To be scaleable the check has to be very quick. In the end it'll sadly
> probably just have to be 'newcomer?'. It sucks but this is existential.
> 
> > This isn't actually a new problem.  In the pre-AI era, we would
> 
> Sorry you're completely wrong, it's entirely a new problem.
> 
> Nobody could drive thousands of at least plausible patches end-to-end with
> little to no input in the past. INCLUDING replies.
> 
> > If AI is making the review problem more challenging, the good news is
> > that there are ways that AI can help.  For example Sashiko can help
> 
> Sashiko only checks if the code is buggy or not, not whether it's worth
> having or is a total mess or not. So completely unhelpful (speaking from
> experience).
> 
> > I also suspect it should be possible to use something like Jev or some
> > other System One LLM to help with an initial prioritization for the
> > patch, and then have that prioritization be set in patchwork.  Each
> 
> Using AI to detect AI right now works, who knows in the future. But that's
> an arms race which we'll eventually lose. Which also costs money...

I'm sure AI companies will disagree with you :-)

> > Using AI-assited priotization may have some collateral damange because
> > it might not get the prioritization correct.  But ultimately, if we
> 
> Any solution will incur collateral damage, sadly inevitable.

-- 
Regards,

Laurent Pinchart

  parent reply	other threads:[~2026-10-19 22:44 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-09  8:31 [PATCH] docs: remove Assisted-by references Sasha Levin
2026-10-09  9:38 ` Laurent Pinchart
2026-10-09 10:09   ` Sasha Levin
2026-10-09 10:05 ` Krzysztof Kozlowski
2026-10-09 10:24   ` Greg KH
2026-10-09 15:20   ` Jonathan Corbet
2026-10-11  1:04     ` Steven Rostedt
2026-10-12 15:42   ` Lorenzo Stoakes (ARM)
2026-10-13 11:19     ` Jori Koolstra
2026-10-13 12:38       ` Laurent Pinchart
2026-10-13 12:50         ` Jori Koolstra
2026-10-13 13:01           ` Laurent Pinchart
2026-10-13 13:24         ` Ricardo B. Marlière (SUSE)
2026-10-13 12:49       ` Lorenzo Stoakes (ARM)
2026-10-13 17:16         ` Laurent Pinchart
2026-10-13 12:31     ` Laurent Pinchart
2026-10-13 12:59       ` Lorenzo Stoakes (ARM)
2026-10-13 13:04         ` Krzysztof Kozlowski
2026-10-13 13:07           ` Lorenzo Stoakes (ARM)
2026-10-13 13:12         ` Laurent Pinchart
2026-10-13 13:29           ` Lorenzo Stoakes (ARM)
2026-10-13 13:37             ` Jori Koolstra
2026-10-13 14:52             ` Kees Cook
2026-10-13 14:54               ` Jori Koolstra
2026-10-13 14:58               ` Jori Koolstra
2026-10-13 17:12                 ` Kees Cook
2026-10-13 17:42                   ` Laurent Pinchart
2026-10-13 19:25                     ` Kees Cook
2026-10-13 20:16                       ` Laurent Pinchart
2026-10-13 20:45                         ` Linus Torvalds
2026-10-14 13:56                           ` Lorenzo Stoakes (ARM)
2026-10-16 14:19                             ` Matthew Brost
2026-10-17 17:42                               ` Troy Benjegerdes
2026-10-19 17:41                           ` lyude
2026-10-14 18:47                         ` Kees Cook
2026-10-15 23:14                           ` Jeremy Dean Clifton
2026-10-13 15:02               ` Lorenzo Stoakes (ARM)
2026-10-13 16:58                 ` Kees Cook
2026-10-13 17:32             ` Laurent Pinchart
2026-10-16 16:14               ` Lorenzo Stoakes (ARM)
2026-10-14  3:23             ` Theodore Tso
2026-10-14 11:23               ` Mark Brown
2026-10-14 13:08               ` Jori Koolstra
2026-10-14 13:42               ` Lorenzo Stoakes (ARM)
2026-10-14 14:15                 ` Mark Brown
2026-10-19 22:44                 ` Laurent Pinchart [this message]
2026-10-20  4:28                   ` Theodore Tso
2026-10-19 16:32               ` lyude
2026-10-19 22:24               ` Laurent Pinchart
2026-10-19 16:26             ` lyude
2026-10-16 18:26           ` Ihor Solodrai
2026-10-19 16:21           ` lyude
2026-10-13  4:24 ` Kees Cook
2026-10-13  5:56   ` Randy Dunlap
2026-10-13  6:18     ` Greg KH
2026-10-13  8:25     ` Kees Cook
2026-10-13 12:28       ` [PATCH] docs: remove Assisted-by reference Jori Koolstra
2026-10-13 12:55         ` Laurent Pinchart
2026-10-13 13:03           ` Jori Koolstra
2026-10-13 13:10             ` Laurent Pinchart
2026-10-13 13:20               ` Jori Koolstra
2026-10-13 13:55                 ` Laurent Pinchart
2026-10-19 16:50                 ` lyude
2026-10-13 15:18           ` Mark Brown
2026-10-13 17:07             ` Laurent Pinchart
2026-10-13 20:01               ` Shuah Khan
2026-10-19 16:15         ` lyude

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261019224448.GC15441@killaraus.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=apw@canonical.com \
    --cc=axboe@kernel.dk \
    --cc=bfoster@redhat.com \
    --cc=brauner@kernel.org \
    --cc=broonie@kernel.org \
    --cc=cem@kernel.org \
    --cc=corbet@lwn.net \
    --cc=david@kernel.org \
    --cc=ddiss@suse.de \
    --cc=federico.vaga@vaga.pv.it \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jani.nikula@intel.com \
    --cc=jkoolstra@xs4all.nl \
    --cc=joe@perches.com \
    --cc=justinstitt@google.com \
    --cc=krzk@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=sashal@kernel.org \
    --cc=skhan@linuxfoundation.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=vbabka@kernel.org \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.