Messages in this thread | | | Subject | Re: [PATCH] x86/nmi: Fix some races in NMI uaccess | From | Rik van Riel <> | Date | Mon, 27 Aug 2018 21:31:37 -0400 |
| |
On Mon, 2018-08-27 at 16:04 -0700, Andy Lutomirski wrote:
> +++ b/arch/x86/mm/tlb.c > @@ -345,6 +345,9 @@ void switch_mm_irqs_off(struct mm_struct *prev, > struct mm_struct *next, > */ > trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH, > TLB_FLUSH_ALL); > } else { > + /* Let NMI code know that CR3 may not match > expectations. */
I don't get it. This is in the "ASID is up to date, do not need a TLB flush" path.
In what case do we have a TLB that is fully up to date, but a CR3 that does not match expectations?
Doesn't the CR3 check in nmi_uaccess_ok already catch the window of time where the CR3 has already been switched over to that of the next task?
What is special about this path wrt nmi_uaccess_ok that is not also true for the need_flush branch right above it?
What am I missing?
> + this_cpu_write(cpu_tlbstate.loaded_mm, NULL); > + > /* The new ASID is already up to date. */ > load_new_mm_cr3(next->pgd, new_asid, false);
-- All Rights Reversed. [unhandled content-type:application/pgp-signature] | |