6 ms·
The analysis of the kernel bug may be a better thing to link to: https://github.com/dfoxfranke/ripgrep-3494-analysis https://github.com/dfoxfranke/ripgrep-3494-
by hyperpape 2mo ago
The analysis of the kernel bug may be a better thing to link to: https://github.com/dfoxfranke/ripgrep-3494-analysis https://github.com/dfoxfranke/ripgrep-3494-analysis.
- yawndex 2mo agosoulless unreadable AI slop
- hoppp 2mo agoI can read it but not sure if worth spending energy on it. It doesn't make sense for the reader to spend more energy than the writer spent on creating it.
- wild_pointer 2mo agoPoC||GTFO, if it reproduces, it's valuable
- deleted 2mo ago[deleted]
- fr2029 2mo ago[dead]
- smallerize 2mo agoThen post whatever notes were fed into the AI instead. The verbosity and self-congratulating add negative value.
- im3w1l 2mo agoWhat will you do when the prompt was "Figure out the bug and write a report for me". Not saying it was in this particular case, but I think at least in other cases, it will be.
- wizzwizz4 2mo agoIt didn't figure out the bug: the report is largely nonsense. It merely did a bad impression of having figured out the bug, by stringing together several observations into something superficially resembling a narrative. Providing those observations without the gibberish framing might be useful.
- derdi 2mo agoThe parent's point still stands. In many cases it will have figured out the bug. In many cases it will have produced a small, clean, deterministic reproducer. In my daily work I see these cases. It does help that the bugs that are filed contain a test case and some analysis by the agent. It would not help to get ten identical bug reports all saying "I asked my agent to find a bug by prompting it with "find a bug and produce a test case". It found a nasty bug and a really nice reproducer. I'm not including its output here. Good luck!"
- 27183 2mo ago> What will you do when the prompt was "Figure out the bug and write a report for me". The rational choice would be to cut your losses and stop reading at that point. Once you realize zero effort went into the prompt, there's no longer any reason to read the output. The age old truism still applies: garbage in, garbage out. If you think it's worthwhile, close the issue with a comment: "please rework this and show your work next time". Otherwise just close it without commenting and move on.
- krupan 2mo ago"it will be" Trying to figure out what to do based on possible future scenarios has a place, but not here when we are talking about a concrete present problem.
- inigyou 2mo agoPrompt an AI to figure out the bug and write a report, of course. If that is actually useful.
- wild_pointer 2mo agoThat I agree with (not instead, in addition)
- inigyou 2mo agoThey have a PoC, we're arguing about the LLM-generated slop explanation of the PoC.
- BetterThanSober 2mo agoIs it actually reproducible though and do I want to chase and reproduce something that had no human touch? Do you?
- wild_pointer 2mo agoIf it's an actual bug, I hope the Linux devs will. It impacted a human, and it's a bug regardless of human or non-human touch. Of course, looking at a bug is a matter of priority, always has been.
- amluto 2mo agoIn the history of Linux that I'm aware of (and I've been nose-deep in this stuff on and off for quite a while), these issues are almost never debugged because they're reproduced -- they're debugged because someone who actually understands the messy interactions of the code and hardware in question thinks about them. A reproducer might not actually be useful because there is basically no way short of fancy hardware tracing to figure out what the reproducer is doing.
- agumonkey 2mo ago> It doesn't make sense for the reader to spend more energy than the writer spent on creating it. Great way to summarize cultural "economics" Couldn't put the words on this pattern but sometimes all I care about is that someone cared about.
- PunchyHamster 2mo agoI usually go for "If I wanted LLM answer I'd ask LLM instead of reading your answer/article/content"
- agumonkey 2mo agoBut it goes beyond this. The whole 2020s era is about cheap ways to do anything and be able to stream it to billions of people. Yet I feel no density in the work because there was no energy spent on it.
- fc417fc802 2mo agoIt's proof of work applied to social interactions. The father back in history you go the rarer I imagine the root problem was. There's a similar conundrum with gifts. When everyone is able to order approximately anything from anywhere in the world via the internet exchanging gifts begins to feel like a bizarre ritual meant only to transfer money to businesses.
- serf 2mo agoenergy might be the wrong metric, plenty of energy was wasted spinning up that LLM.
- shevy-java 2mo agoYeah but the thing is that someone tries to waste time of humans. This is why I hate "interacting" with bots, scripts or AI/LLMs. It just wastes my time, again and again and again. Oddly enough not all humans understand that. About two months ago, a german developer involved with ffmpeg, spam-slopped their mailing list with AI (it was an AI proposal for some change to ffmpeg in the future). He still does not understand why that is a problem.
- inigyou 2mo agoI think it was GZDoom where the absentee project owner suddenly came back, pushed a bunch of nonsense AI comments, so the entire actual development community just forked it again and left him to play in his sandbox? Now it's UZDoom. Something similar happened with PolyMC to PrismLauncher but that wasn't about AI, it was an absentee owner who came back and deleted everything he said was woke.
- rfgplk 2mo agoWhy is it unreadable? I actually find LLM bug reports/breakdowns to be far more detailed and concise that classical human written ones. If you read the linked repo it clearly goes it depth where the bug was found, how to reproduce it (and in depth). Most disclosures that are human written don't do this at all, they barely even tell you _how_ to reproduce the bug. Just look at the "3.3 The self-store tear", the LLM clearly describes exactly what went wrong, so you can verify it by hand.
- walk12111 2mo ago[dead]
- skydhash 2mo agoBecause any writing needs a core intent they need to convey, which you can summarize down to according to the audience and why it should be important to them. Kinda like the same idea of elevator pitches, “explain like I’m five” and tactical reports when there’s a time constraints. You got none of that here. It’s just realms of text.
- rfgplk 2mo agoMaybe the person writing the report isn't an expert in this domain or doesn't have the time to commit to it? From my point of view as long as the information is accurate and reproducible, it's valuable.
- mi_lk 2mo agoThen where’s the lie in “soulless AI slop”?
- applfanboysbgon 2mo ago> From my point of view as long as the information is accurate That's the trillion-dollar catch, isn't it. LLMs love to write 30 paragraphs about some plausibly-correct-sounding explanation that is just as likely to be completely fucking wrong as it is accurate. The bug might be real, but that doesn't mean this analysis is accurate, and trying to figure out where the LLM went off the rails can be a nightmare. If you can actually understand the bug, it doesn't take 30 paragraphs to explain it. I would throw this bug report into my junk bin if I were on the receiving end of it, and I say that as someone who will spend days troubleshooting any issue a user will help me diagnose even if it only happens on their machine.
- anorwell 2mo agoI had the opposite reaction. Clear, detailed, well-organized. Pretty close to the ideal writeup.
- deleted 2mo ago[deleted]
- Retr0id 2mo agoCould you explain it in your own words? (I tried myself, and quickly discovered that it is incoherent)
- porridgeraisin 2mo agoWhat? it is mostly literal nonsense. Moreover the last paragraph where they say it only reproduced on one machine just does not justify the pseudo-deep analysis in the whole document.
- fr2029 2mo ago[dead]
- IshKebab 2mo agoReally? It's chock full of poorly written and irrelevant chain-of-thought rambling.
- orphea 2mo agoHi Claude! :wave:
- munch117 2mo agoPerhaps you are talking about the ripgrep issue itself, which is fine. The others are talking about the linked analysis, which is not.
- deleted 2mo ago[deleted]
- amluto 2mo agoNice sleuthing, nonsense explanation. An extra TLB flush is never an error. (The CPU is free to flush whenever it feels like doing so.) The error seems to be that somehow a zero-page PTE was present when it shouldn’t have been. This sounds to me like either (a) a complex race involving a CPU migration at an awkward time or (b) a bug in the zap path transiently exposing wrong PTEs. Also, I don’t think the zero page has pfn zero. If I had to throw a dart, I would guess that direct page table zapping is allowing a CPU to read through a higher-level-paging-structure cached entry to a table that has been freed and reused. Yuck. I’ve debugged one of these before.
- inigyou 2mo agoThe explanation is obviously written by an AI agent.
- Retr0id 2mo agoThe part that doesn't make sense to me is that trying to read through a zeroed PTE should be an immediate segfault, not something that reads back zeroes (regardless of whether the zero page is pfn 0 (it isn't)). I think the broad strokes are that, due to bad locking in the kernel, mmap() returns a VA that a concurrent munmap() is still in the middle of unmapping. The specifics beyond that seem murky/speculative/inconsistent. Alternatively, it could be a hardware bug, since afaict it's only been repro'd on one hardware config. (I know there are a bunch of ARM cores with erratas around TLB invalidation)
- amluto 2mo agoAfter more digging, I bet it's a paging-structure-cache flush bug. I've debugged these before, and they're nasty, hardware dependent, hard-to-reproduce issues. Looks like the code that the AI flagged might actually be wrong, but not for the reason that the AI thought. https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-ZHY5T_=4QY5+Fn8BM4A@mail.gmail.com/ https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-...
- gpm 2mo ago> Alternatively, it could be a hardware bug, since afaict it's only been repro'd on one hardware config. (I know there are a bunch of ARM cores with erratas around TLB invalidation) Which raises the question of whether any HN readers have successfully reproduced this? I've just tried (using his file generation script and the official rg binary he links) on a Ryzen 7 5800X / 7.1.5-arch1-2 with sufficient free ram as the github issue suggests, and still no segfaults after 10 minutes.
- fwlr 2mo agoThe overflow would still overflow; the use-after-free would still use after free; a musl mask race would still race. Hilarious. Apart from the computer poetry, the conclusion seems to be “it’s something in Linux 7.0 + musl 1.2.5”, although the only reproduction is still on the same physical Threadripper CPU and only sometimes when heavily exercised, so it hasn’t really ruled out a hardware issue.
- internetter 2mo agoThe computer seems to have identified source code to blame though? Unless of course it hallucinated which there’s always a non zero chance of
- fwlr 2mo agoI mean, we are deep into reading tea leaves at this point, but what it seems to have identified is the source file that changed such that this issue can now occur. My gut instinct is that the changed code is still valid and correct, but it exercises the hardware in a different or a more intense way.
- MBCook 2mo agoIt’s the kernel. Nothing a user space library can do should ever be able to call this. Just happens to be that the musl code is able to hit this and other code isn’t for some reason.
- entrope 2mo ago> It’s the kernel. Nothing a user space library can do should ever be able to call this. I don't follow. An application might see this kind of crash if it has a bug causing it to access a page while another thread is mapping or unmapping that page. That would be a bug in mallocng, musl or ripgrep. Or, as someone else mentioned, it could be bug in the processor's virtual memory logic that has the same effect. Why do you say it can only be a kernel bug?
- 2mo ago
- p0nce 2mo agoReading an AI-generated bug report is awful.
- oxidant 2mo agoStopped after > Headline. The crash is real and reproducible.
- BetterThanSober 2mo agoI really hated that kind of language, feels like speaking to a motivator anyway it's slop, can sense it even before i started reading
- bentcorner 2mo agoThe worst thing is that I know there's something interesting in there but I'm too arsed to take the time and decode what data the author must have used to generate that text.
- 27183 2mo agoExactly, it would be so much better if they shared the prompts instead of the output, at least then we'd be able to make some sense of what they were thinking about.
- gjm11 2mo agoUnfortunately the prompt may have been something like "investigate this bug and file an issue when you think you understand what's going on". The "better just to share the prompt" heuristic falls down when the actual underlying intellectual work was also done by the machine. (Feel free to pretend that I used some phrase other than "intellectual work" if you dislike seeing it used to describe something done by AI.)
- 27183 2mo ago
- smukherjee19 2mo agoI tried reading and gave up at the "Headline"... Quoting from the bug analysis: >Headline. The crash is real and reproducible. With musl instrumentation we pin the in-process mechanism precisely: a thread's own store to a freshly- faulted anonymous page becomes invisible to that same thread's reload ~10 instructions later, because the page's backing is replaced mid-function. A pagemap read at the instant of the fault shows the backing is the kernel's zero page. A captured core dump confirms the crash site with matched virtual addresses. The mechanism localizes to the interaction between the per-VMA-lock anonymous-fault fast path and a concurrent munmap's TLB shootdown. A source-level review of Linux 7.0.12 identifies a specific race in that interaction, and a git comparison across v6.19/v7.0/v7.1/mainline identifies the v7.0-introduced change on the munmap-teardown side that widens it. "a thread's own store to a freshly- faulted anonymous page becomes invisible to that same thread's reload ~10 instructions later, because the page's backing is replaced mid-function." -> ??? What's a "backing" of a page? Freshly-faulted? Fresh fries? "~10 instructions later"? "A pagemap read at the instant of the fault shows the backing is the kernel's zero page." -> Backing? "The mechanism localizes to the interaction between the per-VMA-lock anonymous-fault fast path and a concurrent munmap's TLB shootdown." -> How can a mechanism "localize"? And more. This is... words strung together. Nothing more. I wonder how people read and make sense of this. In case people have forgotten what real technical writing looks like, here's a sample (I am not the author): https://yifan.lu/2019/01/11/the-first-f00d-exploit/ https://yifan.lu/2019/01/11/the-first-f00d-exploit/
- Retr0id 2mo agofwiw "backing" is standard jargon in this context, and "freshly faulted" is phrasing you'll see in Linux source comments. The writeup as a whole is indeed slop, though.
- newsoftheday 2mo agoAgreed, the article you linked is a great example of clear, understandable, detailed technical writing.
- cerved 2mo agoI'm becoming increasingly allergic to the performative writing of LLMs. The worst part is how compulsive LLMs are at writing like this. Like the system prompt instructs it to "reason" and like a college Sophomore it pontificates and quotes Nietzsche to fein intelligence and orginal thought.
- kelnos 2mo agoNot really. It's typical rambling LLM slop-analysis. It may be a correct analysis (I couldn't stomach reading it in detail), but it's a pain in the ass to read. A human doing the same analysis would have written something 1/5th the length.