"backing" is a Virtual-Memory related term. With virtual memory, you can have memory areas (called "pages") that are not really there but only present in the metadata (the "book-keeping", so to say). The first time, someone actually tries to access this page, that access is interrupted ("faulted") and the kernel gets a say in what should be done to that piece of memory (i.e. load it from disk somewhere, reserve actual physical memory and fill it with zeroes, or crash the process).
The "backing" refers to the physical memory that might or might not be present for every "virtual" piece of memory that your program has allocated.
"Freshly faulted" means that a page of (virtual) memory has just received a "backing" by the process above and is, thus, very fresh in physical memory (even though the virtual memory might have been allocated much earlier)
"~10 instructions later" refers to the assembly- (machine-) code, which, contrary to a high-level language like C, usually has long(ish) sequences of rather simple "instructions". 10 instructions is a rather short interval in assembly code.
As for the "localize", the term used is actually "localizes to" which I read as "turns out to be located in" (probably just a bad English translation by the original author)
While this whole summary reads a bit weird, I don't think it is necessarily the result of an LLM, it's probably just that someone who is rather inexperienced at writing up technical summaries did it.
I understand all the words in it and follow the argument, but it's still bullshit in the technical sense of being written by someone who wants to sound authoritative but doesn't ultimately care if they are right or wrong.
The write-up should have been about five paragraphs: (1) "The script at https://... generates a tree with X million files taking 20 GB total. Running ripgrep 1.2.34, compiled with musl, on my Threadripper 9876 as 'rg ...' crashes about a fourth of the time. With glibc, it does not crash." (2) "This appears to be a bug introduced by commit abcdef1234 in some_vm_call() that allows a race between [...] such that user space can see a corrupt whatever." (3) "The sequence of operations that causes this is: (show two or more kernel threads with lines interleaved to explain the bug)". (4) and (5) as needed to elaborate on those three core points.
But the actual post is long on (fluent) speculation and short on reference to actual code. That's a large part of why it's offensive slop.
So the theory is that the page is faulted in, then somehow evicted within 10 instructions, then re-faulted in somewhere else, resulting in writes not making it to the page? That would need a context switch and another page fault to happen in short succession. But the context switch to evict the page back out would have necessitated pending writes to have finished. Nothing actually makes sense with that explanation.
The way I read it was that it wrote to a page and then did a read on that page within 10 instructions and that was not enough time for the memory system to have gone through the process of creating the page backed with real memory and that the timing bug widened in Linux 7.0 such that more things like this exposed the bug. Or there was flapping in the TLB for some reason, or the locking wasn’t correct, or whatever else that the kernel devs will figure out was the cause.
I’m guessing it wrote to a page and read back zero page as the memory was in the mist of being allocated.
But the write should have triggered a page fault immediately in that case, and should have been blocked on the page being actually allocated before resuming.
yes, i went back and re-read the report. an immediate read 1 instruction later works, but 10 does not. the page marked dirty but pointing to the zero page. some context flapping i assume
Sounded like a race condition causing a correct new mapping in the TLB to be cleared away by mistake, reverting back to the zero page mapping it was before.
Thanks for the explanation. I should have looked up each term a bit more.
So "backing" is the underlying physical memory the page maps to.
So if I were to make sense of that piece of slop, is this what it would be?
"In one thread, a page fault happens during a store operation. The physical memory address is the proper address, which is immediately (around 10 assembly instructions later) replaced by the 0x00000000 memory address by another thread due to race condition, resulting in a crash when the original thread tries to read that page again."
The first thread is the user program, the other thread is the kernel doing things on another core.
Reading from the zero page is legal, that doesn’t cause it to crash. The crash is because of a logic “bug” in the program where the zero it reads back causes some other issue in the program.
I say “bug” because it’s clearly impossible without the kernel messing up. It just stored a non-zero value there.
Nope. It's more complicated. The store operation does not need to trigger the fault, it can happen for other reasons.
What happens here is a bug in munmap() that happens in another thread. It corrupts the TLB, for a brief instant replacing the correct page.
So that the virtual memory page that the crashed thread tried to read its RAM, it gets replaced by the special zero-filled physical page. The kernel uses this zero page as an optimization when it needs to create a region of data filled with zeroes, so it can just map one physical page over the entire range.
It's a really low-level bug that just requires a lot of specialized knowledge just to explain. A better write-up is certainly possible but needs to have a lot of explanations to make it understandable.
Even though Monkey Island now has a real (i.e. canonical) ending, it sucks. I prefer the original continuation of MI3 to the 25-years-late official, canonical sequel
It's not just the ending, but the flat humor, the lazy puzzles (like clicking multiple times on multiple objects to open the porthole) and the meagre number of interactions on each of the islands after the first one..
It's like his heart just wasn't in it anymore
It felt like a "ehh let's get this over with" at best
or a medium-effort nostalgia-pandering money grab at worst.
It's not even decent nostalgia-pandering, more like an expression of disdain towards the fanbase complete with "art" that can only have been designed to offend.
The link given elsewhere here about the multi-layered aspect of the stories from 1, 2 and RMI gives it a bit more depth. Obviously if you take it on the surface level only it's low effort.
that's a nice fan theory which does involve some very real elements from the game (the meta narrative, the genre awareness, the nearly constant fourth wall breaking, the multiple layers, the ambiguity) but speculates a lot and veers towards some wild hypothesis ("Stan is LeChuck" makes no sense however you put it).
I do appreciate the multi layered aspect, and it's the number one element which keeps me coming back to MI games, and I especially appreciated the way in which RMI felt like a fading dream, with stuff being ever more "slightly off" than before.
But if this is indeed the intended "meaning" of the whole thing, the authors didn't do a great job at it. We get only bits and pieces of this purported hidden "reality", and on the other side we have a couple of very easy to read narrative levels where The Secret is clearly a MacGuffin (a trope the authors love: see the rewards for the three trials, and the treasure being literally called "Big whoop"), the absurdity and the anachronisms are the point, and once it's over the only thing they can say is... the game is over, now turn this off and go do something more interesting, which is a nice joke and sufficiently meta. The issue is that it's ok the first time, but after the third time it's an overused trope
What happens to you in India when you are charged builty of bribery? What are the punishments, if any? (for the person receiving the bribe, not the person bribing, obviously)
Honestly, haven't looked into the legal side in detail. I'm mostly just providing the data (what happened, where), not the legal outcomes. That part's outside what I've built so far.
I think the main problem will be sourcing one of the AMD InterWave chips. Those are (to my knowledge) not produced anymore and the only source would be another GUS card
Wait, being transported in an ambulance costs money? Man, every day I learn new things about how shitty the US health system is, and I'm more and more happy to not have to worry about deciding if I'd rather die or be broke in an emergency
So you can easily get it to work in the browser, but the dozens of core developers can't get it to work properly on Wayland[1]? Something smells fishy...
You can run KiCad just fine on Wayland because XWayland was built for applications like these. The big issues that KiCad can't fix are encountered when running it on Wayland without compatibility tooling.
With the oldschool way KiCad was designed, I don't think they'll ever be natively compatible with Wayland, but thankfully they don't have to.
The "backing" refers to the physical memory that might or might not be present for every "virtual" piece of memory that your program has allocated.
"Freshly faulted" means that a page of (virtual) memory has just received a "backing" by the process above and is, thus, very fresh in physical memory (even though the virtual memory might have been allocated much earlier)
"~10 instructions later" refers to the assembly- (machine-) code, which, contrary to a high-level language like C, usually has long(ish) sequences of rather simple "instructions". 10 instructions is a rather short interval in assembly code.
As for the "localize", the term used is actually "localizes to" which I read as "turns out to be located in" (probably just a bad English translation by the original author)
While this whole summary reads a bit weird, I don't think it is necessarily the result of an LLM, it's probably just that someone who is rather inexperienced at writing up technical summaries did it.
reply