All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Theodore Tso <tytso@mit.edu>
Cc: Shuah Khan <skhan@linuxfoundation.org>,
	Bart Van Assche <bvanassche@acm.org>,
	johannes.goede@oss.qualcomm.com, Jiri Kosina <jikos@kernel.org>,
	ksummit@lists.linux.dev, sashiko@lists.linux.dev
Subject: Re: Patch pre-submission to Sashiko
Date: Wed, 21 Oct 2026 17:33:15 +0100	[thread overview]
Message-ID: <atjpS__OwjZ-Q_Fh@sirena.org.uk> (raw)
In-Reply-To: <atjlUoEmTagZjrYI@mit.edu>

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

On Wed, Oct 21, 2026 at 12:20:43PM -0400, Theodore Tso wrote:
> On Wed, Oct 21, 2026 at 12:07:09PM -0500, Mark Brown wrote:

> > TBH having seen some LLM patches that come with LLM generated testcases
> > the testcases are much worse than the patches themselves.  Open coding,
> > weird structures, asserting bizzare things without explanation - just
> > generally really hard to understand what the test is trying to
> > accomplish and why.

> I recently posted a patch[1] to add KUnit tests for
> fs/ext4/extents_status.c.  It was completely AI generated, and used
> these instructions which I gave to Gemini Pro[2].

> [1] https://lore.kernel.org/all/20261021031231.40107-1-tytso@mit.edu/
> [2] https://lore.kernel.org/all/atbZWze194QiSOTe@mit.edu/

> I'm obviously biased, but it seems to me these test cases were pretty
> good.  I'd appreciate criticisms and suggestions for improvements, but
> if your experience is test cases written with older models, the latest
> frontier models have gotten way better.

Yeah, it's not that you can't do it but rather that I'm nervous of how
much of a useful gate it is to require tests - my general feel is that
if the commits have problems then any associated tests tend to have more
problems.  One example I reviewed earlier today is here:

   https://lore.kernel.org/r/ed22ebf64ed00a56d5e1eff31ac639fef00dcae6.1792179433.git.ivanrwcm25@gmail.com

which will get the issue it was looking for but isn't something I'd want
to maintain long term.

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

  reply	other threads:[~2026-10-21 16:33 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-17 17:28 Patch pre-submission to Sashiko Jiri Kosina
2026-10-17 18:02 ` Theodore Tso
2026-10-19 11:02   ` johannes.goede
2026-10-19 20:27     ` Theodore Tso
2026-10-20 14:20       ` Bart Van Assche
2026-10-20 19:21         ` Theodore Tso
2026-10-20 20:15           ` Miguel Ojeda
2026-10-20 20:43           ` Shuah Khan
2026-10-21 11:07             ` Mark Brown
2026-10-21 16:20               ` Theodore Tso
2026-10-21 16:33                 ` Mark Brown [this message]
2026-10-21 18:45                   ` Andrew Morton
2026-10-21 19:15                     ` Rafael J. Wysocki (Intel)
2026-10-21 19:56                     ` Theodore Tso
2026-10-21 20:10                     ` Jiri Kosina
2026-10-21 20:24                       ` Steven Rostedt
2026-10-21 20:46                     ` Paul E. McKenney
2026-10-17 18:20 ` Alexei Starovoitov
2026-10-17 18:38   ` Arnaldo Melo
2026-10-19  7:02     ` Dan Carpenter
2026-10-18 11:46   ` Mark Brown
2026-10-17 18:20 ` Linus Torvalds
2026-10-17 20:10   ` Roman Gushchin
2026-10-18 13:41     ` Steven Rostedt
2026-10-18 18:41     ` Kees Cook
2026-10-18 18:58       ` Linus Torvalds
2026-10-19  5:55   ` Oliver Slapinski
2026-10-17 19:42 ` Andrew Lunn
2026-10-18 11:54   ` Mark Brown
2026-10-18 16:48     ` Laurent Pinchart
2026-10-19  6:25 ` Krzysztof Kozlowski
2026-10-19  7:26   ` David Woodhouse
2026-10-19 11:40     ` Michal Simek
2026-10-19 12:02       ` Julia Lawall
2026-10-19 12:46         ` Michal Simek
2026-10-19 12:57           ` Julia Lawall
2026-10-19 17:30             ` Rodrigo Vivi
2026-10-19 17:53   ` Shuah Khan
2026-10-19 18:17     ` Arnaldo Melo
2026-10-19 20:35     ` Theodore Tso
2026-10-20  2:28       ` Chen-Yu Tsai
2026-10-20  8:36       ` Jiri Kosina
2026-10-20  8:48         ` Vlastimil Babka (SUSE)

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=atjpS__OwjZ-Q_Fh@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=jikos@kernel.org \
    --cc=johannes.goede@oss.qualcomm.com \
    --cc=ksummit@lists.linux.dev \
    --cc=sashiko@lists.linux.dev \
    --cc=skhan@linuxfoundation.org \
    --cc=tytso@mit.edu \
    /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.