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 18:44:51
Also in: lkml

On 10/26/21 10:44 AM, Nadav Amit wrote:
quoted
"If software on one logical processor writes to a page while software on
another logical processor concurrently clears the R/W flag in the
paging-structure entry that maps the page, execution on some processors may
result in the entry’s dirty flag being set (due to the write on the first
logical processor) and the entry’s R/W flag being clear (due to the update
to the entry on the second logical processor). This will never occur on a
processor that supports control-flow enforcement technology (CET)”

So I guess that this optimization can only be enabled when CET is enabled.

:(
I still wonder whether the SDM comment applies to present bit vs dirty
bit atomicity as well.
I think it's implicit.  From "4.8 ACCESSED AND DIRTY FLAGS":

	"Whenever there is a write to a linear address, the processor
	 sets the dirty flag (if it is not already set) in the paging-
	 structure entry"

There can't be a "write to a linear address" without a Present=1 PTE.
If it were a Dirty=1,Present=1 PTE, there's no race because there might
not be a write to the PTE at all.

There's also this from the "4.10.4.3 Optional Invalidation" section:

	"no TLB entry or paging-structure cache entry is created with
	 information from a paging-structure entry in which the P flag
 	 is 0."

That means that we don't have to worry about the TLB doing something
bonkers like caching a Dirty=1 bit from a Present=0 PTE.

Is that what you were worried about?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help