undefined

points

[-]

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.

by sroussey3 hours ago|

parent|

[-]

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.

by yuliyp2 hours ago|

parent|

[-]

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.

by MBCook4 hours ago|

parent|

prev|

[-]

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.

by inigyou3 hours ago|

parent|

[-]

Except incorrectly flushing the TLB would merely be a performance bug.

by entrope3 hours ago|

prev|

[-]

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.

by smukherjee195 hours ago|

prev|

[-]

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."

by MBCook3 hours ago|

parent|

[-]

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.

by cyberax3 hours ago|

parent|

prev|

[-]

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.