[yuliyp]

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.

[sroussey]

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.

[yuliyp]

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.

[sroussey]

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

[MBCook]

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.

[inigyou]

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