Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1435676
| From | Benjamin Herrenschmidt <benh@kernel.crashing.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 0/4] [RFC][v4] Workaround for Xeon Phi PTE A/D bits erratum |
| Date | 2016-07-02 01:10 +0200 |
| Message-ID | <rQfJo-4hb-5@gated-at.bofh.it> (permalink) |
| References | <rQaJI-16J-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, 2016-07-01 at 10:46 -0700, Dave Hansen wrote: > The Intel(R) Xeon Phi(TM) Processor x200 Family (codename: Knights > Landing) has an erratum where a processor thread setting the Accessed > or Dirty bits may not do so atomically against its checks for the > Present bit. This may cause a thread (which is about to page fault) > to set A and/or D, even though the Present bit had already been > atomically cleared. Interesting.... I always wondered where in the Intel docs did it specify that present was tested atomically with setting of A and D ... I couldn't find it. Isn't there a more fundamental issue however that you may actually lose those bits ? For example if we do an munmap, in zap_pte_range() We first exchange all the PTEs with 0 with ptep_get_and_clear_full() and we then transfer D that we just read into the struct page. We rely on the fact that D will never be set again, what we go it a "final" D bit. IE. We rely on the fact that a processor either: - Has a cached PTE in its TLB with D set, in which case it can still write to the page until we flush the TLB or - Doesn't have a cached PTE in its TLB with D set and so will fail to do so due to the atomic P check, thus never writing. With the errata, don't you have a situation where a processor in the second category will write and set D despite P having been cleared (due to the race) and thus causing us to miss the transfer of that D to the struct page and essentially completely miss that the physical page is dirty ? (Leading to memory corruption). > If the PTE is used for storing a swap index or a NUMA migration index, > the A bit could be misinterpreted as part of the swap type. The stray > bits being set cause a software-cleared PTE to be interpreted as a > swap entry. In some cases (like when the swap index ends up being > for a non-existent swapfile), the kernel detects the stray value > and WARN()s about it, but there is no guarantee that the kernel can > always detect it. > > This patch changes the kernel to attempt to ignore those stray bits > when they get set. We do this by making our swap PTE format > completely ignore the A/D bits, and also by ignoring them in our > pte_none() checks. > > Andi Kleen wrote the original version of this patch. Dave Hansen > wrote the later ones.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH 0/4] [RFC][v4] Workaround for Xeon Phi PTE A/D bits erratum Dave Hansen <dave@sr71.net> - 2016-07-01 19:50 +0200 [PATCH 2/4] x86, pagetable: ignore A/D bits in pte/pmd/pud_none() Dave Hansen <dave@sr71.net> - 2016-07-01 19:50 +0200 [PATCH 1/4] x86, swap: move swap offset/type up in PTE to work around erratum Dave Hansen <dave@sr71.net> - 2016-07-01 19:50 +0200 [PATCH 4/4] x86: use pte_none() to test for empty PTE Dave Hansen <dave@sr71.net> - 2016-07-01 19:50 +0200 [PATCH 3/4] x86: disallow running with 32-bit PTEs to work around erratum Dave Hansen <dave@sr71.net> - 2016-07-01 19:50 +0200 Re: [PATCH 0/4] [RFC][v4] Workaround for Xeon Phi PTE A/D bits erratum Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2016-07-02 01:10 +0200
csiph-web