[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a4b0be3f-bb6f-42d7-9176-a2bc0dcbd3a8@meta.com>
Date: Mon, 12 Jan 2026 09:36:25 -0500
From: Chris Mason <clm@...a.com>
To: Vlastimil Babka <vbabka@...e.cz>,
Roman Gushchin <roman.gushchin@...ux.dev>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Christoph Lameter <cl@...two.org>,
David Rientjes <rientjes@...gle.com>, Harry Yoo <harry.yoo@...cle.com>,
Uladzislau Rezki <urezki@...il.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Suren Baghdasaryan <surenb@...gle.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Alexei Starovoitov <ast@...nel.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
bpf@...r.kernel.org, kasan-dev@...glegroups.com,
Petr Tesarik <ptesarik@...e.com>,
"Paul E . McKenney" <paulmck@...nel.org>
Subject: Re: [PATCH RFC 10/19] slab: remove cpu (partial) slabs usage from
allocation paths
On 1/10/26 10:41 AM, Vlastimil Babka wrote:
> On 1/10/26 14:20, Chris Mason wrote:
>> On 1/9/26 3:16 AM, Vlastimil Babka wrote:
>>> On 10/24/25 16:29, Chris Mason wrote:
>>>> On Thu, 23 Oct 2025 15:52:32 +0200 Vlastimil Babka <vbabka@...e.cz> wrote:
>>
>> [ ... ]
>>
>>> By the way, there was another bug in this patch, causing a severe memory
>>> leak, which the AI unfortunately didn't flag. Petr reported it during
>>> performance testing and it took me more than a day to find it. Oh well :)
>>>
>>> Wonder if things got better since then perhaps, and your or Roman's tools
>>> would find it today? :)
>>
>> Yes and no. It didn't find the leak until I changed the prompt to say:
>> "there is a leak, find it". I'll see if I can improve things...
>
> Thanks. Hmm even if it has to be done like this, it could be a substantial
> time saver vs finding the leak myself.
Finding the missing break on the first pass was tricky because claude
consistently focused on concerns about potential NULL pointers and
mostly ignored the loop flow control changes.
I think I've fixed things by expanding the loop analysis and also
forcing it to make a more fine grained list of changes to analyze before
it jumps into the review.
It caught the missing break 5 out of 6 times in a loop, so maybe?
That's probably the best I can get right now for a generic review, but
claude will almost always be more reliable with extra directions like
"there is a leak, find it" on top of the review prompt.
I've pushed out two new commits to:
https://github.com/masoncl/review-prompts
9a44c271 CS-001.md: pay more attention to loop control flow and memory
allocations
7fad3996 review-core.md: make change categories more fine grained
Thanks for flagging this, I think/hope it'll handle complex changes more
effectively now across the board.
-chris
Powered by blists - more mailing lists