Linux Kernel Summit discussions
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Roman Gushchin <roman.gushchin@linux.dev>
Cc: ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process
Date: Wed, 15 Jul 2026 15:57:57 -0300	[thread overview]
Message-ID: <20260715185757.GA191552@nvidia.com> (raw)
In-Reply-To: <7ia4qzl45h20.fsf@castle.c.googlers.com>

On Wed, Jul 15, 2026 at 04:55:03PM +0000, Roman Gushchin wrote:
> * Handling of pre-existing bugs.
> Currently, Sashiko reports pre-existing bugs alongside new issues
> (while trying hard to highlight that these issues were not introduced by
> the proposed change). This approach comes with significant pros (a
> steady stream of bug fixes) and cons (additional noise and workload for
> maintainers). I am considering a database of pre-existing issues to
> ensure they are reported only once (or once per year), with an option
> for the respective maintainers to flag them as false positives. This
> will also provide maintainers an access to a deduplicated and ranked
> list of potential issues in their subsystem’s codebase.

I would really like a syzkaller like dashboard of all these
pre-existing issues and a nag/summary email so they actually get
fixed.

I've gone and fixed a bunch on my own, mostly out of fear that they
will just disappear and be lost, but it is an annoying urgency. I'd
rather have as a giant todo list (that maybe other people could help
with too)

Often alot of tokens are spent to find these things, it feels wrong
that they are effectively lost in the endless stream of reviews..

> * Prompt development and testing.
> Currently, prompts are maintained in two GitHub repositories and are
> changed manually or with the help of AI coding agents. However, there is
> no established practice for testing them, especially across various LLM
> models. At the last LSFMMBPF conference, there was a discussion about
> moving them into the kernel tree. I see some pros and cons to this
> approach, but the ownership and testing models are not entirely clear.

Having them in the kernel always felt better to me, I wonder what the
cons are.

> Many engineers have asked for some sort of interactive mode where they
> can ask additional questions or follow up on the initial feedback from
> Sashiko. I plan to add this to the local review mode, but for the
> central public instance, it is problematic from both security and token
> cost perspectives. 

Could there some way to download the entire context from all the passes
to a local environment and have a local llm chew on it to answer
questions?

Jason

  parent reply	other threads:[~2026-07-15 18:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15 16:55 [MAINTAINERS SUMMIT] The place of AI code review in the Linux Kernel process Roman Gushchin
2026-07-15 17:51 ` Miguel Ojeda
2026-07-15 21:37   ` Roman Gushchin
2026-07-15 17:56 ` Mauro Carvalho Chehab
2026-07-15 18:57 ` Jason Gunthorpe [this message]
2026-07-15 21:21   ` Roman Gushchin
2026-07-15 19:45 ` Dmitry Torokhov
2026-07-16  0:03 ` Steven Rostedt
2026-07-16  0:30 ` SJ Park

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=20260715185757.GA191552@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=ksummit@lists.linux.dev \
    --cc=roman.gushchin@linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox