[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221107171419.k33qd4rz3tyfrovs@box.shutemov.name>
Date: Mon, 7 Nov 2022 20:14:19 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Andy Lutomirski <luto@...nel.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>, x86@...nel.org,
Kostya Serebryany <kcc@...gle.com>,
Andrey Ryabinin <ryabinin.a.a@...il.com>,
Andrey Konovalov <andreyknvl@...il.com>,
Alexander Potapenko <glider@...gle.com>,
Taras Madan <tarasmadan@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
"H . J . Lu" <hjl.tools@...il.com>,
Andi Kleen <ak@...ux.intel.com>,
Rick Edgecombe <rick.p.edgecombe@...el.com>,
Bharata B Rao <bharata@....com>,
Jacob Pan <jacob.jun.pan@...ux.intel.com>,
Ashok Raj <ashok.raj@...el.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCHv11 04/16] x86/mm: Handle LAM on context switch
On Mon, Nov 07, 2022 at 06:58:59AM -0800, Andy Lutomirski wrote:
> > @@ -554,6 +561,7 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
> > if (real_prev == next) {
> > VM_WARN_ON(this_cpu_read(cpu_tlbstate.ctxs[prev_asid].ctx_id) !=
> > next->context.ctx_id);
> > + VM_WARN_ON(prev_lam != new_lam);
>
> What prevents this warning from firing if a remote cpu does
> prctl_enable_tagged_addr() and this cpu hits this code path before getting
> the LAM-enabling IPI? Conceptually this would be like if we asserted that
> LDTR matched the mm_context's ldt setting in this code path.
>
> I think (haven't really verified) that you can fix this by removing the
> warning and adding a comment explaining that CR3 can be out of sync due to a
> race against changes to LAM settings. I don't think there's any way to
> eliminate the race -- there is no lock you can take while changing lam that
> prevents a remote CPU from switching mm or scheduling.
Something like this?
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index d6c9c15d2ad2..c6cac1a1bc64 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -561,7 +561,15 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
if (real_prev == next) {
VM_WARN_ON(this_cpu_read(cpu_tlbstate.ctxs[prev_asid].ctx_id) !=
next->context.ctx_id);
- VM_WARN_ON(prev_lam != new_lam);
+
+ /*
+ * 'prev_lam' does not necessary match 'new_lam' here. In case
+ * of race with LAM enabling, the updated 'lam_cr3_mask' can be
+ * been before LAM-enabling IPI kicks in.
+ *
+ * The race is harmless: it is okay to update CR3 with new LAM
+ * mode. The IPI will rewrite CR3 shortly.
+ */
/*
* Even in lazy TLB mode, the CPU should stay set in the
--
Kiryl Shutsemau / Kirill A. Shutemov
Powered by blists - more mailing lists