Hi Lorenzo, Thanks for your review. I would like to respond to your points, quoting your mail below.
> NAK. I understand your right to NAK as a maintainer. I am not asking you to withdraw it automatically. I am clarifying the facts. > This series is buggy, and has triggered my AI detection script. If there are real bugs, I will fix them. But an AI-detection script finding bugs is not proof that the code was generated by an LLM. Automated review tools commonly find bugs in complex kernel code. The dhm series has been in development for a long time and has gone through several versions; the dynamic core isolation design touches many kernel subsystems, so bugs found by automated review are not surprising. > It is kernel policy that you must disclose this with an > Assisted-by tag like: > > Assisted-by: LLM I agree with this policy. I did not use an LLM to generate the patch code, but I used GLM to help run test data. I will disclose the GLM use; if an Assisted-by tag is required, I will add it. If I ever use an LLM to generate code, I will disclose that as well. > It is also kernel policy that you must fully understand and take > responsibility for every patch that you send. I understand and take full responsibility for every patch I send. > The script noted: > > - Output rate: since 09-28 he has sent KVM SMM CR3/Hyper-V, > ext4+jbd2+quota "shrinker scan budget accounting" (the same fix > applied to three shrinkers; jbd2 went v1->v5 in 3 days and v1->v3 > in 3 hours), blk-mq SRCU tag sets, a blk-mq sync-run, ublk x2, > a 4-patch bpf-next verifier rework, mm/migrate move_pages (v2 > sent 10h after v1) and this series. That is ~9 unrelated deep > areas in 4 days from someone with 4 commits. I respect this guidance. I do not often have time to send patches to the community; work keeps me busy. I am not spamming. I only recently had time to send work that has been in progress for months: - The dhm series has been developed for a long time and has gone through several versions. The dynamic core isolation design touches many kernel subsystems, so bugs found by automated review are common. - The bpf series is something I started while optimizing bpf earlier but did not have time to finish. Similar work was attempted in 2019, it is complex and not easy to write, and this has been pending for more than 9 months. - The KVM SMM CR3/Hyper-V fix comes from a real problem I hit using Win11 WSL2 + virt-manager. I fixed it internally a long time ago but did not push it upstream. I only sent it after finding Win11 still had not fixed it. - I have been working on storage for the past few months. The ext4+jbd2+quota changes are the same logic in three places; once one was found, fixing the others followed naturally, as documented in kernel docs. The v1 of those three small patches already received Reviewed-by tags; I only made small changes and added test data after a reviewer raised a different opinion. - blk-mq, ublk, mm/migrate, and mm/compaction are performance issues I found while working on heterogeneous KV-cache AI optimization over the past months, using perf, ftrace, bpf, etc. > Given you sent your first mail on 21st September and have since > been spamming complicated series across multiple different > domains, I'm absolutely not confident that you have any > understanding of this. I am not spamming. I only recently had time to send work that has been in progress for months. The areas are not unrelated from my side: they come from storage, virtualization, BPF, and heterogeneous KV-cache AI optimization work. > It also noted that you had a previous email, [email protected], > which you have silent switched from, which also bore the > hallmarks of AI slop. [email protected] was an old personal email address. I no longer want to use it, so I switched to [email protected]. There was no intent to hide anything; it is simply an email change. > It also found several glaring flaws with your series, so it's > clearly not upstreamable. If there are concrete flaws, please point them out, or I will go through the Sashiko findings one by one and fix them. Thanks, Qiliang
