Re: [PATCH] mm/damon: introduce DAMON-based NUMA memory tiering module

["David Hildenbrand (Arm)" <david@kernel.org>]

On 3/26/26 17:39, Josh Law wrote:
> 
> 
> On 26 March 2026 16:33:30 GMT, "Lorenzo Stoakes (Oracle)" <ljs@kernel.org> wrote:
>> On Thu, Mar 26, 2026 at 04:10:42PM +0000, Josh Law wrote:
>>>
>>> I will be absolutely transparent with all of you here, The commit descriptions
>>  (The long ones), Use AI, to be exact! Claude sonnet 4.6,
>>>
>>> Additionally, I will make a promise here,
>>> All of the bug fixes I made, all of my lib/ bug fixes, are made fully by me,
>>> (minus the commit description for some of them) And I can promise you that on
>>> the bible, If you have any questions about this, You can always ask me
>>>
>>> Forth thing: My patch volume
>>>
>>> To justify my patch volume, I am a "excited" Developer, I love the Linux
>>  kernel, and I have a passion for that, I am very very sorry I filled up your
>>  mailbox with my slop descriptions
>>
>> You're obviously lying, and you're not very good at it.
>>
>> To reiterate:
>>
>>  Assessment: ~95% probability all contributions are AI-generated. The
>>  evidence is overwhelming:
>>
>>  1. Volume is humanly implausible — ~30 emails/day, 5–10 new patch
>>     submissions per day across unrelated subsystems, from a contributor
>>     with zero prior history.
>>
>>  2. Breadth is the strongest signal — no human newcomer simultaneously
>>     finds subtle bugs in bootconfig, vsprintf, base64, bch, maple_tree,
>>     assoc_array, io_uring, AND writes a new DAMON NUMA tiering
>>     module. Each of these requires deep domain-specific knowledge. The
>>     pattern is consistent with an LLM being pointed at different source
>>     files to systematically find issues.
>>
>>  3. Bug-finding pattern — the patches cluster around unchecked return
>>     values, type mismatches, resource leaks, off-by-ones, signed/unsigned
>>     issues. This is exactly what an LLM produces when scanning code for
>>     potential problems.
>>
>>  4. Rapid revision cycling — bootconfig went from v1 to v8 in ~1 day. This
>>     matches AI regeneration, not human revision.
>>
>>  5. Feature additions from a newcomer — glob_match_nocase(),
>>     glob_validate(), debugfs BUG/WARN interface, and the DAMON NUMA
>>     tiering module are all non-trivial features. A first-time contributor
>>     proposing features (not just fixes) across this many subsystems
>>     simultaneously is essentially unheard of.
>>
>>  6. Zero ramp-up — the contribution stream started at full throughput with
>>     no learning curve visible.
>>
>> Please go away.
>>
>> and >/dev/null to any further correspondence from you, other than NAK's when
>> necessary.
> 
> 
> I am withdrawing all pending patches, I am not gonna even touch artificial intelligence again, and I am going to take a couple months break

Josh,

in general we try to be a welcoming upstream community. Finding people
that are willing to work on the low-level bits and stick around is rare.

At the same time, we need people that are willing to get familiar with
the code base and technology, so they can help out with review and
provide long-term value to the project. AI use is only partially useful
in that context. Certainly not for writing patches as a newbie. At best,
to double-check your understanding (e.g., AI review), help you learn
(e.g., explore the code base), or improve your writing if your English
is really, really bad.

I prefer someone trying to use their own words to compose a change log
and actually learn something on the way over some AI slop that reads
nicer any day. Often, when you write a changelog you actually realize
which corner cases you might be missing, that the design might be overly
complicated, that, maybe, the reasoning or motivation is bad etc. It
takes time but you actually learn something and are forced to think
(crazy, right?).

The same is particularly true when it comes to writing documentation, as
people raised earlier in other context.

Having that said, your actions made a lot of people's alarms go off and
there is pretty much 0 trust now. As Lorenzo says, even now we are not
really sure if you are saying the truth right now, which is a big problem.

If you are, in fact, a real person, and are passionate to work on the
kernel, it would be best if you would start things very slowly and don't
use any AI for crafting your patches (including patch descriptions).
Stick to one subsystem and ask people what good starting tasks/projects
could be.

Ideally, you'd find someone people trust around here, that can verify
your identity (i.e., have a video chat etc) and start mentoring you on
how to start working in the kernel community and gain trust.

Now, I am still not sure whether I am talking to a bot here (there are
too many things Lorenzo points out above that are very suspicious), but
I just wanted to say that there are ways to become a trusted
contributor, and that information might be useful for other people that
might be interested in working on the kernel.

It's certainly not by flooding the list with AI slop.

-- 
Cheers,

David