Thread (33 messages) 33 messages, 6 authors, 2021-10-26

Re: [PATCH v2 2/5] mm: avoid unnecessary flush on change_huge_pmd()

From: Dave Hansen <hidden>
Date: 2021-10-26 20:47:47
Also in: lkml

On 10/26/21 1:07 PM, Nadav Amit wrote:
I just wonder how come the R/W-clearing and the P-clearing cause concurrent
dirty bit setting to behave differently. I am not a hardware guy, but I would
imagine they would be the same...
First of all, I think the non-atomic properties where a PTE can go:

	W=1,D=0 // original
	W=0,D=0 // software clears W
	W=0,D=1 // hardware sets D

were a total implementation accident.  It wasn't someone being clever
and since the behavior was architecturally allowed and well-tolerated by
software it was around for a while.  I think I was the one that asked
that it get fixed for shadow stacks, and nobody pushed back on it too
hard as far as I remember.  I don't think it was super hard to fix.

Why do the Present/Accessed and Write/Dirty pairs act differently?  I
think it's a total implementation accident and wasn't by design.

The KNL erratum was an erratum and wasn't codified in the architecture
because it actually broke things.  The pre-CET Write/Dirty behavior
didn't break software  to a level it was considered an erratum.  It gets
to live on as allowed in the architecture.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help