drm AI patch review hacks

drm AI patch review hacks

[Dave Airlie]

Hi all,

This came up at kernel maintainers summit, so I've been trying to see
what I can piece together, and have a small demonstration that may be
useful to some people.

I didn't want to pollute the mailing list with AI patch reviews, so I
decided to set up a public-inbox that the reviews are pushed into.
This isn't currently automated, I'm just asking claude to pull the
last 2-3 days of patches and review what is new every so often.

The workflow use lei to pull mails to local PC, use review-prompts +
my own prompt to try and review a patch series, both as a complete
work, and per-patch reviews, then create the reply emails and put them
into a public inbox git tree for publishing.

I've no idea if it's using review-prompts properly or at all, this is
all very vibe coded so far.

https://lore.gitlab.freedesktop.org/drm-ai-reviews/

This is a public inbox, you can also git clone

https://gitlab.freedesktop.org/drm/ai-reviews-public-inbox

I'm currently just using my Red Hat provided claude with opus 4.6,
until I get told I've burned enough money.

The list below are the patches with reviews, if someone wants to look
and give feedback on whether the reviews for their series are useful,
find any bugs or regressions, that would be cool.

I've bcc'd anyone who has a patch on the list.

This is also just an experiment to see what might stick, it might
disappear at any time, and it probably needs a lot of tuning.

Thanks,
Dave.

[PATCH v2 0/2] drm/buddy: Documentation and internal helper cleanup
[PATCH] drm/amd/display: Remove duplicate include
[PATCH -next v9 0/3] rust: Add CList and GPU buddy allocator bindings
[PATCH V1] accel/amdxdna: Fix suspend failure after enabling turbo mode
[PATCH V1] accel/amdxdna: Fix dead lock for suspend and resume
[PATCH v1] drm/tyr: gpu: fix GpuInfo::log model/version decoding
[PATCH v2 0/2] drm/vkms: Fix bad matrix offset component multiplication
[PATCH 1/2] accel/amdxdna: Fix NULL pointer dereference in mailbox
channel cleanup
[PATCH] drm/msm: always recover the gpu
[PATCH drm-misc-next] drm: verisilicon: assign git tree to drm/misc in
MAINTAINERS
[PATCH drm-misc-next 0/3] drm: verisilicon: convert drm_format to
vs_format in atomic_check
[PATCH v3 3/3] drm/panel: add LXD M9189A panel driver
[PATCH v1 0/2] ARM: tegra: document Tegra20 HDMI port
[PATCH] fbcon: Declare struct fb_info.fbcon_par as of type struct fbcon_par
[PATCH v1] drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notify
[PATCH v9 0/7] User readable error codes on atomic_ioctl failure
[PATCH] accel/qaic: Fix dma_free_attrs() buffer size
[PATCH] drm/radeon: Add HAINAN clock adjustment
[PATCH] drm/amdgpu: Add HAINAN clock adjustment
[PATCH v9 01/15] drm/bridge: analogix_dp: Add &analogix_dp_plat_data.next_bridge
[PATCH v2 0/5] drm/ci: add new jobs, uprev IGT and mesa
[PATCH] drm/bridge: lt9611: Remove DRM_BRIDGE_OP_MODES flag
[PATCH 0/6] Support for the Pixel 3a XL with the Tianma panel
[PATCH -next v8 0/3] rust: Add CList and GPU buddy allocator bindings
[PATCH] drm/bridge: samsung-dsim: Fix memory leak in error path
[PATCH] drm/rockchip: vop2: Use drm_err_ratelimited() for wait timeouts
[PATCH] fbcon: Remove struct fbcon_display.inverse
[PATCH 1/5] dma-mapping: avoid random addr value print out on error path
[PATCH v3 2/6] drm/gem-shmem: Test for existence of page in mmap fault handler
[PATCH] gpu: host1x: Fix passing zero to ERR_PTR in host1x_iommu_attach()
[PATCH AUTOSEL 6.18-5.10] drm/tegra: hdmi: sor: Fix error: variable
‘j’ set but not used
[PATCH] drm/mediatek: dsi: Store driver data before invoking
mipi_dsi_host_register
[PATCH] drm/i915/guc: fix corrupted copyright symbols in selftest files
[PATCH v7 4/5] ARM: dts: microchip: sam9x7: Add GFX2D GPU
[PATCH] drm/panel: ilitek-ili9882t: Fine-tune HFP for tianma, tl121bvms07-00
[PATCH v4 1/8] drm/amdkfd: Add userptr batch allocation UAPI structures

Re: drm AI patch review hacks

[Chris Mason]

On 2/11/26 2:44 PM, Dave Airlie wrote:
> Hi all,
> 
> This came up at kernel maintainers summit, so I've been trying to see
> what I can piece together, and have a small demonstration that may be
> useful to some people.
> 
> I didn't want to pollute the mailing list with AI patch reviews, so I
> decided to set up a public-inbox that the reviews are pushed into.
> This isn't currently automated, I'm just asking claude to pull the
> last 2-3 days of patches and review what is new every so often.
> 
> The workflow use lei to pull mails to local PC, use review-prompts +
> my own prompt to try and review a patch series, both as a complete
> work, and per-patch reviews, then create the reply emails and put them
> into a public inbox git tree for publishing.
> 
> I've no idea if it's using review-prompts properly or at all, this is
> all very vibe coded so far.
> 
> https://urldefense.com/v3/__https://lore.gitlab.freedesktop.org/drm-ai-reviews/__;!!Bt8RZUm9aw!7ZGHjZ_cowu_q5cPVL_mOXmzkCeCUgALho-xJLBTCSi_FtnWbpG5rNYrxBZfhrfg24G7LkJ4$ 
> 
> This is a public inbox, you can also git clone
> 
> https://urldefense.com/v3/__https://gitlab.freedesktop.org/drm/ai-reviews-public-inbox__;!!Bt8RZUm9aw!7ZGHjZ_cowu_q5cPVL_mOXmzkCeCUgALho-xJLBTCSi_FtnWbpG5rNYrxBZfhrfg27r4vy3o$ 
> 
> I'm currently just using my Red Hat provided claude with opus 4.6,
> until I get told I've burned enough money.
> 
> The list below are the patches with reviews, if someone wants to look
> and give feedback on whether the reviews for their series are useful,
> find any bugs or regressions, that would be cool.
> 
> I've bcc'd anyone who has a patch on the list.
> 
> This is also just an experiment to see what might stick, it might
> disappear at any time, and it probably needs a lot of tuning.

The output is pretty different from netdev/bpf:

https://lore.kernel.org/bpf/?q=AI+reviewed+your+patch

Which might be what you want so it's fine of course.  But it looks like
it didn't actually go through the report generation from the review
prompts, so I'm worried it didn't use the rest of the prompts either.

My stuff should be creating a review-inline.txt which is the lkml
formatted review.

I'm happy to try things out here if it'll help.

-chris

Re: drm AI patch review hacks

[Dave Airlie]

On Thu, 12 Feb 2026 at 06:02, Chris Mason <clm@meta.com> wrote:
>
>
>
> On 2/11/26 2:44 PM, Dave Airlie wrote:
> > Hi all,
> >
> > This came up at kernel maintainers summit, so I've been trying to see
> > what I can piece together, and have a small demonstration that may be
> > useful to some people.
> >
> > I didn't want to pollute the mailing list with AI patch reviews, so I
> > decided to set up a public-inbox that the reviews are pushed into.
> > This isn't currently automated, I'm just asking claude to pull the
> > last 2-3 days of patches and review what is new every so often.
> >
> > The workflow use lei to pull mails to local PC, use review-prompts +
> > my own prompt to try and review a patch series, both as a complete
> > work, and per-patch reviews, then create the reply emails and put them
> > into a public inbox git tree for publishing.
> >
> > I've no idea if it's using review-prompts properly or at all, this is
> > all very vibe coded so far.
> >
> > https://urldefense.com/v3/__https://lore.gitlab.freedesktop.org/drm-ai-reviews/__;!!Bt8RZUm9aw!7ZGHjZ_cowu_q5cPVL_mOXmzkCeCUgALho-xJLBTCSi_FtnWbpG5rNYrxBZfhrfg24G7LkJ4$
> >
> > This is a public inbox, you can also git clone
> >
> > https://urldefense.com/v3/__https://gitlab.freedesktop.org/drm/ai-reviews-public-inbox__;!!Bt8RZUm9aw!7ZGHjZ_cowu_q5cPVL_mOXmzkCeCUgALho-xJLBTCSi_FtnWbpG5rNYrxBZfhrfg27r4vy3o$
> >
> > I'm currently just using my Red Hat provided claude with opus 4.6,
> > until I get told I've burned enough money.
> >
> > The list below are the patches with reviews, if someone wants to look
> > and give feedback on whether the reviews for their series are useful,
> > find any bugs or regressions, that would be cool.
> >
> > I've bcc'd anyone who has a patch on the list.
> >
> > This is also just an experiment to see what might stick, it might
> > disappear at any time, and it probably needs a lot of tuning.
>
> The output is pretty different from netdev/bpf:
>
> https://lore.kernel.org/bpf/?q=AI+reviewed+your+patch
>
> Which might be what you want so it's fine of course.  But it looks like
> it didn't actually go through the report generation from the review
> prompts, so I'm worried it didn't use the rest of the prompts either.
>
> My stuff should be creating a review-inline.txt which is the lkml
> formatted review.
>
> I'm happy to try things out here if it'll help.

My plan over the next few days is to refine the code to make sure it's
doing this, my prompt asks it to load the patch and the kernel
prompts, then do a review across the series and individual patches,

I'm guessing some of the results aren't making it back out the other side.

Dave.

Re: drm AI patch review hacks

[Linus Torvalds]

On Wed, 11 Feb 2026 at 11:45, Dave Airlie <airlied@gmail.com> wrote:
>
> Hi all,
> This is a public inbox, you can also git clone
>
> https://gitlab.freedesktop.org/drm/ai-reviews-public-inbox

What an odd format that is, and I don't have anything that reads it
natively, so I just did a one-liner script for it:

  git show $(git rev-list HEAD | sed 's/$/:m/')

and having done that I think the review output format is not exactly
lovely, but whatever.

But the details in reviews look mostly pretty good to me. I don't know
the code in question well enough to say whether they are useful to
*you*, but it certainly doesn't look bad to me.

The one review I reacted to was because I *do* know the code enough.
So when Claude reacted to this nonsense patch with that whole "Fix
passing zero to ERR_PTR" thing:

  -       return ERR_PTR(err);
  +       return err ? ERR_PTR(err) : NULL;

*muy* reaction is that it's the opposite of a "fix" and we should get
rid of that whole

        err ? ERR_PTR(err) : NULL

pattern, and just admit that ERR_PTR(err) works fine for 0.

I don't know who started doing that "turn 0 into NULL explicitly"
originally or why, but we certainly shouldn't add to them.

Yes, Claude seems to think that ERR_PTR(0) is "erroneous" and somehow
different from NULL, and maybe that's where some of the existing users
came from? People who already used claude and got the wrong impression
from that?

Claude is correct that casting a non-constant zero value to a pointer
*technically* isn't NULL according to the C standards. But we don't do
standard C, and the fact is, we depend on NULL being not just
"constant 0" at compile time, but also actually have the (dynamic)
value of zero.

However, Claude's other reaction to it is actually much more
interesting than my initial "that's just a nonsense patch".  So while
I disagree with the claude on a detail, I don't think it was overall
bad.

          Linus

Re: drm AI patch review hacks

[Chris Mason]

On 2/11/26 3:05 PM, Dave Airlie wrote:
> On Thu, 12 Feb 2026 at 06:02, Chris Mason <clm@meta.com> wrote:
>>

[ ... ]

>>> This is also just an experiment to see what might stick, it might
>>> disappear at any time, and it probably needs a lot of tuning.
>>
>> The output is pretty different from netdev/bpf:
>>
>> https://lore.kernel.org/bpf/?q=AI+reviewed+your+patch 
>>
>> Which might be what you want so it's fine of course.  But it looks like
>> it didn't actually go through the report generation from the review
>> prompts, so I'm worried it didn't use the rest of the prompts either.
>>
>> My stuff should be creating a review-inline.txt which is the lkml
>> formatted review.
>>
>> I'm happy to try things out here if it'll help.
> 
> My plan over the next few days is to refine the code to make sure it's
> doing this, my prompt asks it to load the patch and the kernel
> prompts, then do a review across the series and individual patches,
> 
> I'm guessing some of the results aren't making it back out the other side.

I had to change the prompts a bit, I think my original instructions were:

"read prompt xyz and patch abc, review the patch"

But sometimes claude would read the prompt and the patch and then follow
it's own review protocol instead of mine.  The current /kreview slash
command is a lot more reliable:

Read the prompt <path to prompts dir>/kernel/review-core.md

If a git range is provided, it's meant for the false-positive-guide.md
section

Using the prompt, do a deep dive regression analysis of the top commit,
or the provided patch/commit

-chris

Re: drm AI patch review hacks

[Dave Airlie]

On Thu, 12 Feb 2026 at 06:17, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, 11 Feb 2026 at 11:45, Dave Airlie <airlied@gmail.com> wrote:
> >
> > Hi all,
> > This is a public inbox, you can also git clone
> >
> > https://gitlab.freedesktop.org/drm/ai-reviews-public-inbox
>
> What an odd format that is, and I don't have anything that reads it
> natively, so I just did a one-liner script for it:
>
>   git show $(git rev-list HEAD | sed 's/$/:m/')

public-inbox-v2 I think it's called.

lei q -o ai-rev -I https://lore.gitlab.freedesktop.org/drm-ai-reviews
"(rt:1.day.ago..)"

will produce a local mailbox with the reviews in it that you can point
mutt at as well

There are also tools I think that will inject things from lei into
gmail, but I haven't played there yet.

>
> and having done that I think the review output format is not exactly
> lovely, but whatever.

Well the idea is to have it use lore so that users can get it using
lei/b4 into mboxes so it fits their workflow.
I just published the public inbox git tree in case it makes it easier
for someone to use lei with.

> But the details in reviews look mostly pretty good to me. I don't know
> the code in question well enough to say whether they are useful to
> *you*, but it certainly doesn't look bad to me.
>
> The one review I reacted to was because I *do* know the code enough.
> So when Claude reacted to this nonsense patch with that whole "Fix
> passing zero to ERR_PTR" thing:
>
>   -       return ERR_PTR(err);
>   +       return err ? ERR_PTR(err) : NULL;
>
> *muy* reaction is that it's the opposite of a "fix" and we should get
> rid of that whole

And I think as I figure out using the prompts properly etc these sort
of things will go away.

> However, Claude's other reaction to it is actually much more
> interesting than my initial "that's just a nonsense patch".  So while
> I disagree with the claude on a detail, I don't think it was overall
> bad.

Dave.

Re: drm AI patch review hacks

[Jason Gunthorpe]

On Thu, Feb 12, 2026 at 05:44:46AM +1000, Dave Airlie wrote:
> Hi all,
> 
> This came up at kernel maintainers summit, so I've been trying to see
> what I can piece together, and have a small demonstration that may be
> useful to some people.

My two cents.. A few years back someone was talking about AI code
reviews at a conference and a bunch of us had a good laugh about it.

Today what Chris has working is, frankly, pretty amazing and should be
taken very seriously. It absolutely finds real problems that are
surprisingly complicated. I think it is a much higher value than a
tool like Coverity or other prior attempts I've seen at static
analysis..

Even if it is often wrong, it is still often *right*. In RDMA land we
are also experimenting with Chris's tools. Your approach is also very
interesting, I think.

At NVIDIA we are trialing some commercial review tools and they are
pretty impressive too. I was working on something unrelated and it
pointed out a real bug in a kernel driver, then it pointed out several
pre-existing stack-leak security bugs too as a drive-by. I thought it
reflected a surprisingly sophisticated evaluation of Linux
requirements, and it wasn't using Chris's Linux specific aides either.

After seeing these reports I used Claude as a super-charged Coccinelle
to look for narrow stack leak patterns across ~300 functions and it
did a very impressive job identifying the target functions, examining
the code, the struct layouts and identifying cases that were actually
problematic, largely autonomously, with a two sentence prompt. Found
another stack-leak bug this way.

This week I've tackled a giant "all driver collateral evolution" type
project in RDMA that is well beyond what I could manage with
Coccinelle.  Using Claude to generate Coccinelle, and do it's own
search/replace has been really eye opening what is now possible with
surprisingly little effort.

It is hard to tell where things will be in a years time, but there has
been a big capability improvement over the last year.

Interesting times ahead for sure!

Jason

Re: drm AI patch review hacks

[Jiri Pirko]

Wed, Feb 11, 2026 at 08:44:46PM +0100, airlied@gmail.com wrote:
>Hi all,
>
>This came up at kernel maintainers summit, so I've been trying to see
>what I can piece together, and have a small demonstration that may be
>useful to some people.
>
>I didn't want to pollute the mailing list with AI patch reviews, so I
>decided to set up a public-inbox that the reviews are pushed into.
>This isn't currently automated, I'm just asking claude to pull the
>last 2-3 days of patches and review what is new every so often.
>
>The workflow use lei to pull mails to local PC, use review-prompts +
>my own prompt to try and review a patch series, both as a complete
>work, and per-patch reviews, then create the reply emails and put them
>into a public inbox git tree for publishing.
>
>I've no idea if it's using review-prompts properly or at all, this is
>all very vibe coded so far.
>
>https://lore.gitlab.freedesktop.org/drm-ai-reviews/
>
>This is a public inbox, you can also git clone
>
>https://gitlab.freedesktop.org/drm/ai-reviews-public-inbox
>
>I'm currently just using my Red Hat provided claude with opus 4.6,
>until I get told I've burned enough money.
>
>The list below are the patches with reviews, if someone wants to look
>and give feedback on whether the reviews for their series are useful,
>find any bugs or regressions, that would be cool.

Overall for my patchset I think the feedback looks pretty much accurate.
What I like is that is even considered the email disscussion about one
of the patches. But since you ran the AI one-shot, does it make sense?
The disscussion may evolve and the verdict with arguments may be stall
(not our case). Eventually when AI-re-run after every reply might be
needed, in that case, better to have the output publised on
a continuously updated web somewhere perhaps, not over emails?

[...]

Re: drm AI patch review hacks

[Chris Mason]

On 2/11/26 2:44 PM, Dave Airlie wrote:
> Hi all,
> 
> This came up at kernel maintainers summit, so I've been trying to see
> what I can piece together, and have a small demonstration that may be
> useful to some people.
> 
> I didn't want to pollute the mailing list with AI patch reviews, so I
> decided to set up a public-inbox that the reviews are pushed into.
> This isn't currently automated, I'm just asking claude to pull the
> last 2-3 days of patches and review what is new every so often.
> 
> The workflow use lei to pull mails to local PC, use review-prompts +
> my own prompt to try and review a patch series, both as a complete
> work, and per-patch reviews, then create the reply emails and put them
> into a public inbox git tree for publishing.
> 
> I've no idea if it's using review-prompts properly or at all, this is
> all very vibe coded so far.

Speaking of vibe coding, I took some commits with Fixes: tags and ran
them through claude to identify subsystem specific knowledge that would
make it more effective at reviewing.  The results for drm are here:

https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/drm.md

I'm happy to adjust of course, this is just a basic starting point.

-chris

Re: drm AI patch review hacks

[Dave Airlie]

On Fri, 13 Feb 2026 at 11:29, Chris Mason <clm@meta.com> wrote:
>
> On 2/11/26 2:44 PM, Dave Airlie wrote:
> > Hi all,
> >
> > This came up at kernel maintainers summit, so I've been trying to see
> > what I can piece together, and have a small demonstration that may be
> > useful to some people.
> >
> > I didn't want to pollute the mailing list with AI patch reviews, so I
> > decided to set up a public-inbox that the reviews are pushed into.
> > This isn't currently automated, I'm just asking claude to pull the
> > last 2-3 days of patches and review what is new every so often.
> >
> > The workflow use lei to pull mails to local PC, use review-prompts +
> > my own prompt to try and review a patch series, both as a complete
> > work, and per-patch reviews, then create the reply emails and put them
> > into a public inbox git tree for publishing.
> >
> > I've no idea if it's using review-prompts properly or at all, this is
> > all very vibe coded so far.
>
> Speaking of vibe coding, I took some commits with Fixes: tags and ran
> them through claude to identify subsystem specific knowledge that would
> make it more effective at reviewing.  The results for drm are here:
>
> https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/drm.md
>
> I'm happy to adjust of course, this is just a basic starting point.

Oh interesting, I might try folding that into my prompts next week,

I've written a blog post with what I've been doing

https://airlied.blogspot.com/2026/02/drm-subsystem-ai-patch-review.html

and a link to the current claude generated reviewer script and prompts
I'm using.

Dave.

Re: drm AI patch review hacks

[Rodrigo Vivi]

On Wed, Feb 11, 2026 at 03:24:49PM -0500, Chris Mason wrote:
> 
> 
> On 2/11/26 3:05 PM, Dave Airlie wrote:
> > On Thu, 12 Feb 2026 at 06:02, Chris Mason <clm@meta.com> wrote:
> >>
> 
> [ ... ]
> 
> >>> This is also just an experiment to see what might stick, it might
> >>> disappear at any time, and it probably needs a lot of tuning.
> >>
> >> The output is pretty different from netdev/bpf:
> >>
> >> https://lore.kernel.org/bpf/?q=AI+reviewed+your+patch 
> >>
> >> Which might be what you want so it's fine of course.  But it looks like
> >> it didn't actually go through the report generation from the review
> >> prompts, so I'm worried it didn't use the rest of the prompts either.
> >>
> >> My stuff should be creating a review-inline.txt which is the lkml
> >> formatted review.
> >>
> >> I'm happy to try things out here if it'll help.
> > 
> > My plan over the next few days is to refine the code to make sure it's
> > doing this, my prompt asks it to load the patch and the kernel
> > prompts, then do a review across the series and individual patches,
> > 
> > I'm guessing some of the results aren't making it back out the other side.
> 
> I had to change the prompts a bit, I think my original instructions were:
> 
> "read prompt xyz and patch abc, review the patch"
> 
> But sometimes claude would read the prompt and the patch and then follow
> it's own review protocol instead of mine.  The current /kreview slash
> command is a lot more reliable:
> 
> Read the prompt <path to prompts dir>/kernel/review-core.md
> 
> If a git range is provided, it's meant for the false-positive-guide.md
> section
> 
> Using the prompt, do a deep dive regression analysis of the top commit,
> or the provided patch/commit

Chris, first of all congrats on this work. I definitely loved the results
I've seen so far.

I hope my question doesn't bring here the old LLM discussions. But based
on the old discussions and people afraid of AI slops in the Linux Kernel
and the potential increase of noise in the review processes, I got myself
wondering if it would be possible to add in your tool some prompt to flag
if the patch/series is a potential AI Slop.

Something like using the AI to detect AI generated code that was not
complying with our good-players guidelines.

Have you considered something like that?

Thanks,
Rodrigo.

> 
> -chris
> 

Re: drm AI patch review hacks

[Chris Mason]

On 2/19/26 2:23 PM, Rodrigo Vivi wrote:
> On Wed, Feb 11, 2026 at 03:24:49PM -0500, Chris Mason wrote:
>>
>>
>> On 2/11/26 3:05 PM, Dave Airlie wrote:
>>> On Thu, 12 Feb 2026 at 06:02, Chris Mason <clm@meta.com> wrote:
>>>>
>>
>> [ ... ]
>>
>>>>> This is also just an experiment to see what might stick, it might
>>>>> disappear at any time, and it probably needs a lot of tuning.
>>>>
>>>> The output is pretty different from netdev/bpf:
>>>>
>>>> https://lore.kernel.org/bpf/?q=AI+reviewed+your+patch  
>>>>
>>>> Which might be what you want so it's fine of course.  But it looks like
>>>> it didn't actually go through the report generation from the review
>>>> prompts, so I'm worried it didn't use the rest of the prompts either.
>>>>
>>>> My stuff should be creating a review-inline.txt which is the lkml
>>>> formatted review.
>>>>
>>>> I'm happy to try things out here if it'll help.
>>>
>>> My plan over the next few days is to refine the code to make sure it's
>>> doing this, my prompt asks it to load the patch and the kernel
>>> prompts, then do a review across the series and individual patches,
>>>
>>> I'm guessing some of the results aren't making it back out the other side.
>>
>> I had to change the prompts a bit, I think my original instructions were:
>>
>> "read prompt xyz and patch abc, review the patch"
>>
>> But sometimes claude would read the prompt and the patch and then follow
>> it's own review protocol instead of mine.  The current /kreview slash
>> command is a lot more reliable:
>>
>> Read the prompt <path to prompts dir>/kernel/review-core.md
>>
>> If a git range is provided, it's meant for the false-positive-guide.md
>> section
>>
>> Using the prompt, do a deep dive regression analysis of the top commit,
>> or the provided patch/commit
> 
> Chris, first of all congrats on this work. I definitely loved the results
> I've seen so far.
> 
> I hope my question doesn't bring here the old LLM discussions. But based
> on the old discussions and people afraid of AI slops in the Linux Kernel
> and the potential increase of noise in the review processes, I got myself
> wondering if it would be possible to add in your tool some prompt to flag
> if the patch/series is a potential AI Slop.

Alexei had asked for something similar, so I did put a few lines into
the prompts for it, but I haven't spent a lot of time defining the
signals that might get used to detect AI generated patches.

Right now it mostly seems to detect AI generated commit messages, and
while I haven't been paying really close attention, the ones it does
flag don't seem to be better or worse and commits than the rest.

Example, scroll down to the end of this email:

https://lore.kernel.org/all/2ddebc81fe2a7d80441d6cf3d27bf6973a4d0a233d6fdbb332d09700775d7f86@mail.kernel.org/

There's review metadata at the bottom, you can search for
"AI-authorship-score: medium"

I didn't find any "high" in a really quick search.

If you have a couple of clear examples, I'm happy to try and build out
the rules to better catch them.  I'd like to focus on bugs instead of
the slop part, but one does tend to lead to the other.

-chris

Re: drm AI patch review hacks

[Icenowy Zheng]

Hi Dave,

It looks like the review bot does not see any extra contexts than those
included in the patch file?

I am trying to address the issues (if valid) raised by the bot of my
patchset `[PATCH drm-misc-next 0/3] drm: verisilicon: convert
drm_format to vs_format in atomic_check' .

In the bot review of 3/3, I got the following review note:

```
After this patch, the format is converted and stored in atomic_check.
However, we should verify the existing
`drm_atomic_helper_check_plane_state()` call (if any) happens after our
format validation. Looking at the patch, I don't see where plane state
validation happens.
```

However, the function already returns with
`drm_atomic_helper_check_plane_state()` call at the tail. It's not part
of the patch (because `git diff` just truncates at the code acquiring
the new CRTC state, which is prequisite for calling
`drm_atomic_helper_check_plane_state()` ), but always part of the
codebase.

This shows that the bot cannot see the existing codebase, but only the
patches themselves. This sounds like some problem.

Hope this could be fixed, although it sounds like this will make the
bot more token-burning.

Thanks
Icenowy

在 2026-02-12四的 05:44 +1000，Dave Airlie写道：
> Hi all,
> 
> This came up at kernel maintainers summit, so I've been trying to see
> what I can piece together, and have a small demonstration that may be
> useful to some people.
> 
> I didn't want to pollute the mailing list with AI patch reviews, so I
> decided to set up a public-inbox that the reviews are pushed into.
> This isn't currently automated, I'm just asking claude to pull the
> last 2-3 days of patches and review what is new every so often.
> 
> The workflow use lei to pull mails to local PC, use review-prompts +
> my own prompt to try and review a patch series, both as a complete
> work, and per-patch reviews, then create the reply emails and put
> them
> into a public inbox git tree for publishing.
> 
> I've no idea if it's using review-prompts properly or at all, this is
> all very vibe coded so far.
> 
> https://lore.gitlab.freedesktop.org/drm-ai-reviews/
> 
> This is a public inbox, you can also git clone
> 
> https://gitlab.freedesktop.org/drm/ai-reviews-public-inbox
> 
> I'm currently just using my Red Hat provided claude with opus 4.6,
> until I get told I've burned enough money.
> 
> The list below are the patches with reviews, if someone wants to look
> and give feedback on whether the reviews for their series are useful,
> find any bugs or regressions, that would be cool.
> 
> I've bcc'd anyone who has a patch on the list.
> 
> This is also just an experiment to see what might stick, it might
> disappear at any time, and it probably needs a lot of tuning.
> 
> Thanks,
> Dave.
> 
> [PATCH v2 0/2] drm/buddy: Documentation and internal helper cleanup
> [PATCH] drm/amd/display: Remove duplicate include
> [PATCH -next v9 0/3] rust: Add CList and GPU buddy allocator bindings
> [PATCH V1] accel/amdxdna: Fix suspend failure after enabling turbo
> mode
> [PATCH V1] accel/amdxdna: Fix dead lock for suspend and resume
> [PATCH v1] drm/tyr: gpu: fix GpuInfo::log model/version decoding
> [PATCH v2 0/2] drm/vkms: Fix bad matrix offset component
> multiplication
> [PATCH 1/2] accel/amdxdna: Fix NULL pointer dereference in mailbox
> channel cleanup
> [PATCH] drm/msm: always recover the gpu
> [PATCH drm-misc-next] drm: verisilicon: assign git tree to drm/misc
> in
> MAINTAINERS
> [PATCH drm-misc-next 0/3] drm: verisilicon: convert drm_format to
> vs_format in atomic_check
> [PATCH v3 3/3] drm/panel: add LXD M9189A panel driver
> [PATCH v1 0/2] ARM: tegra: document Tegra20 HDMI port
> [PATCH] fbcon: Declare struct fb_info.fbcon_par as of type struct
> fbcon_par
> [PATCH v1] drm/amdgpu: fix sync handling in
> amdgpu_dma_buf_move_notify
> [PATCH v9 0/7] User readable error codes on atomic_ioctl failure
> [PATCH] accel/qaic: Fix dma_free_attrs() buffer size
> [PATCH] drm/radeon: Add HAINAN clock adjustment
> [PATCH] drm/amdgpu: Add HAINAN clock adjustment
> [PATCH v9 01/15] drm/bridge: analogix_dp: Add
> &analogix_dp_plat_data.next_bridge
> [PATCH v2 0/5] drm/ci: add new jobs, uprev IGT and mesa
> [PATCH] drm/bridge: lt9611: Remove DRM_BRIDGE_OP_MODES flag
> [PATCH 0/6] Support for the Pixel 3a XL with the Tianma panel
> [PATCH -next v8 0/3] rust: Add CList and GPU buddy allocator bindings
> [PATCH] drm/bridge: samsung-dsim: Fix memory leak in error path
> [PATCH] drm/rockchip: vop2: Use drm_err_ratelimited() for wait
> timeouts
> [PATCH] fbcon: Remove struct fbcon_display.inverse
> [PATCH 1/5] dma-mapping: avoid random addr value print out on error
> path
> [PATCH v3 2/6] drm/gem-shmem: Test for existence of page in mmap
> fault handler
> [PATCH] gpu: host1x: Fix passing zero to ERR_PTR in
> host1x_iommu_attach()
> [PATCH AUTOSEL 6.18-5.10] drm/tegra: hdmi: sor: Fix error: variable
> ‘j’ set but not used
> [PATCH] drm/mediatek: dsi: Store driver data before invoking
> mipi_dsi_host_register
> [PATCH] drm/i915/guc: fix corrupted copyright symbols in selftest
> files
> [PATCH v7 4/5] ARM: dts: microchip: sam9x7: Add GFX2D GPU
> [PATCH] drm/panel: ilitek-ili9882t: Fine-tune HFP for tianma,
> tl121bvms07-00
> [PATCH v4 1/8] drm/amdkfd: Add userptr batch allocation UAPI
> structures

Re: drm AI patch review hacks

[Dave Airlie]

On Thu, 5 Mar 2026 at 17:40, Icenowy Zheng <zhengxingda@iscas.ac.cn> wrote:
>
> Hi Dave,
>
> It looks like the review bot does not see any extra contexts than those
> included in the patch file?

It has access to the latest drm-next, and should try and reference it
in reviews.

But if something has changed in drm-misc-next for example, it won't
know about it, it's hard to pick a base that is consistent and won't
chew tokens every time it needs to update.

Dave.