3 ms·

Heh, from the kernel patch: https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-ZHY5T_=4QY5+Fn8BM4A@mail.gmail.com/ https://lore.kernel.org/all/CALCETrX

Heh, from the kernel patch: https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-ZHY5T_=4QY5+Fn8BM4A@mail.gmail.com/ https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-... > I saw a fun bug report in ripgrep and a studious but pretty bad AI-generated analysis Referring to https://github.com/dfoxfranke/ripgrep-3494-analysis https://github.com/dfoxfranke/ripgrep-3494-analysis which I indeed thought "that's an awful lot written to have been written by a human." Looks like that thread is from...today!

vaughands 2mo ago
Thanks for the fun read.
vintagedave 2mo ago
That was a tough read, but in all the verbiage I do not see it identifying the same code or area as the real genuine human on lore.kernel. For those who can understand Claude better than me: did it anywhere actually identify the issue?
- gpm 2mo ago
  Assuming Andy (the mailing list post) is right, no it didn't. I know this because he said so here in this comment section: https://news.ycombinator.com/item?id=49134550 https://news.ycombinator.com/item?id=49134550 That said the AI was sort of directionality right... it identified roughly the right code.
gruntled-worker 2mo ago
Until ~2000, "cellphone user in public" equated with "smug asshole." We're at that icky rejection stage with AI. Two years ago, that writeup would have been viewed as a generous gift of time to the community. Now we can't be bothered to read through it because we know where it came from, and that it's just worth $0.06 in tokens. Another reason (I think) is because we know what it portends. In a few years, digging manually through bugs will probably be a last resort. We'll go from sneering to yawning at the reports, as another AI agent reads them and verifies the fix. Just like we ignore compiler-generated assembly code and people on their cellphones.
- doubletwoyou 2mo ago
  If we know ‘where it came from’ in the sense that the author couldn’t even bother writing anything themselves, why should other people bother reading this deluge of nonsensical strung together words?
  - gruntled-worker 2mo ago
    That's my point, we won't bother reading it. We'll let agents read it. People will eventually stop getting ticked off at this stuff. One exception: if the model is poor or on 'low' and that leads to a crappy report. That's the equivalent of shipping performance-critical code built with -O0 in the compiler analogy.
    - krageon 2mo ago
      This is a crappy report, that's what is being discussed
      - gruntled-worker 2mo ago
        Is there any indication that it was a mini/fast/older model, or on a low effort level? My read of the reactions above is "ugh AI", not "ugh AI on the cheap". Not a single poster mentioned model or effort choice. It seems more like the usual irritation at "AI slop". If you just mean that the result was technically incorrect or off, that's probably true, but it doesn't affect my argument.
        monitron 2mo ago
        At work I am sitting on a small pile of incomplete/wrong/missing-the-point bug reports right now, all generated by Opus 5 on High effort. Even under good conditions, LLMs are still wrong quite a lot, and confidently so. I can see why you think instant dismissal of LLM generated work is shallow, but I think it's at least as shortsighted to assume that when it creates poor quality work it must be an old/cheap model, bad settings, bad prompting, etc.
benmmurphy 2mo ago
Looking at the function the addr value should always equal end but also it looks like on x86 this value is discarded in pte_free_tlb so maybe this is not the problem or I’m looking at a different version. https://github.com/torvalds/linux/blob/master/mm/memory.c#L1975 https://github.com/torvalds/linux/blob/master/mm/memory.c#L1... Assuming addr is a virtual address it probably makes sense that pte_free_tlb does not need it. https://github.com/torvalds/linux/blob/master/arch/x86/mm/pgtable.c#L21 https://github.com/torvalds/linux/blob/master/arch/x86/mm/pg...
tonfa 2mo ago
Patch was applied yesterday by Linus: https://lore.kernel.org/all/20260804003708.49830-1-luto@kernel.org/ https://lore.kernel.org/all/20260804003708.49830-1-luto@kern...

vaughands 2mo ago

Thanks for the fun read.

vintagedave 2mo ago

That was a tough read, but in all the verbiage I do not see it identifying the same code or area as the real genuine human on lore.kernel. For those who can understand Claude better than me: did it anywhere actually identify the issue?

gpm 2mo ago
Assuming Andy (the mailing list post) is right, no it didn't. I know this because he said so here in this comment section: https://news.ycombinator.com/item?id=49134550 https://news.ycombinator.com/item?id=49134550 That said the AI was sort of directionality right... it identified roughly the right code.

gruntled-worker 2mo ago

Until ~2000, "cellphone user in public" equated with "smug asshole." We're at that icky rejection stage with AI. Two years ago, that writeup would have been viewed as a generous gift of time to the community. Now we can't be bothered to read through it because we know where it came from, and that it's just worth $0.06 in tokens. Another reason (I think) is because we know what it portends. In a few years, digging manually through bugs will probably be a last resort. We'll go from sneering to yawning at the reports, as another AI agent reads them and verifies the fix. Just like we ignore compiler-generated assembly code and people on their cellphones.

doubletwoyou 2mo ago
If we know ‘where it came from’ in the sense that the author couldn’t even bother writing anything themselves, why should other people bother reading this deluge of nonsensical strung together words?
- gruntled-worker 2mo ago
  That's my point, we won't bother reading it. We'll let agents read it. People will eventually stop getting ticked off at this stuff. One exception: if the model is poor or on 'low' and that leads to a crappy report. That's the equivalent of shipping performance-critical code built with -O0 in the compiler analogy.
  - krageon 2mo ago
    This is a crappy report, that's what is being discussed
    - gruntled-worker 2mo ago
      Is there any indication that it was a mini/fast/older model, or on a low effort level? My read of the reactions above is "ugh AI", not "ugh AI on the cheap". Not a single poster mentioned model or effort choice. It seems more like the usual irritation at "AI slop". If you just mean that the result was technically incorrect or off, that's probably true, but it doesn't affect my argument.
      - monitron 2mo ago
        At work I am sitting on a small pile of incomplete/wrong/missing-the-point bug reports right now, all generated by Opus 5 on High effort. Even under good conditions, LLMs are still wrong quite a lot, and confidently so. I can see why you think instant dismissal of LLM generated work is shallow, but I think it's at least as shortsighted to assume that when it creates poor quality work it must be an old/cheap model, bad settings, bad prompting, etc.

benmmurphy 2mo ago

Looking at the function the addr value should always equal end but also it looks like on x86 this value is discarded in pte_free_tlb so maybe this is not the problem or I’m looking at a different version. https://github.com/torvalds/linux/blob/master/mm/memory.c#L1975 https://github.com/torvalds/linux/blob/master/mm/memory.c#L1... Assuming addr is a virtual address it probably makes sense that pte_free_tlb does not need it. https://github.com/torvalds/linux/blob/master/arch/x86/mm/pgtable.c#L21 https://github.com/torvalds/linux/blob/master/arch/x86/mm/pg...

tonfa 2mo ago

Patch was applied yesterday by Linus: https://lore.kernel.org/all/20260804003708.49830-1-luto@kernel.org/ https://lore.kernel.org/all/20260804003708.49830-1-luto@kern...