linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: kirill@shutemov.name
To: Andy Lutomirski <luto@kernel.org>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	dave.hansen@intel.com, ak@linux.intel.com, andreyknvl@gmail.com,
	ashok.raj@intel.com, bharata@amd.com,
	dave.hansen@linux.intel.com, dvyukov@google.com,
	glider@google.com, hjl.tools@gmail.com,
	jacob.jun.pan@linux.intel.com, kcc@google.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	peterz@infradead.org, rick.p.edgecombe@intel.com,
	ryabinin.a.a@gmail.com, tarasmadan@google.com, x86@kernel.org
Subject: Re: [PATCHv11.1 04/16] x86/mm: Handle LAM on context switch
Date: Wed, 9 Nov 2022 12:17:42 +0300	[thread overview]
Message-ID: <20221109091742.tpqxho5kvdmrto3r@box.shutemov.name> (raw)
In-Reply-To: <6782d309-5e4b-580c-fbbb-4388bda69bf3@kernel.org>

On Tue, Nov 08, 2022 at 07:54:35PM -0800, Andy Lutomirski wrote:
> On 11/7/22 13:35, Kirill A. Shutemov wrote:
> > Linear Address Masking mode for userspace pointers encoded in CR3 bits.
> > The mode is selected per-process and stored in mm_context_t.
> > 
> > switch_mm_irqs_off() now respects selected LAM mode and constructs CR3
> > accordingly.
> > 
> > The active LAM mode gets recorded in the tlb_state.
> > 
> 
> > +static inline unsigned long mm_lam_cr3_mask(struct mm_struct *mm)
> > +{
> > +	return mm->context.lam_cr3_mask;
> 
> READ_ONCE -- otherwise this has a data race and might generate sanitizer
> complaints.

Yep, thanks for pointing it out.

> > +}
> 
> > @@ -491,6 +496,8 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
> >   {
> >   	struct mm_struct *real_prev = this_cpu_read(cpu_tlbstate.loaded_mm);
> >   	u16 prev_asid = this_cpu_read(cpu_tlbstate.loaded_mm_asid);
> > +	unsigned long prev_lam = tlbstate_lam_cr3_mask();
> > +	unsigned long new_lam = mm_lam_cr3_mask(next);
> 
> So I'm reading this again after drinking a cup of coffee.  new_lam is next's
> LAM mask according to mm_struct (and thus can change asynchronously due to a
> remote CPU).  prev_lam is based on tlbstate and can't change asynchronously,
> at least not with IRQs off.
> 
> 
> >   	bool was_lazy = this_cpu_read(cpu_tlbstate_shared.is_lazy);
> >   	unsigned cpu = smp_processor_id();
> >   	u64 next_tlb_gen;
> > @@ -520,7 +527,7 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
> >   	 * isn't free.
> >   	 */
> >   #ifdef CONFIG_DEBUG_VM
> > -	if (WARN_ON_ONCE(__read_cr3() != build_cr3(real_prev->pgd, prev_asid))) {
> > +	if (WARN_ON_ONCE(__read_cr3() != build_cr3(real_prev->pgd, prev_asid, prev_lam))) {
> 
> So is the only purpose of tlbstate_lam_cr3_mask() to enable this warning to
> work?

Right. And disabling CONFIG_DEBUG_VM leads to warning. See the fixup
below.

> >   		/*
> >   		 * If we were to BUG here, we'd be very likely to kill
> >   		 * the system so hard that we don't see the call trace.
> > @@ -552,9 +559,15 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
> >   	 * instruction.
> >   	 */
> >   	if (real_prev == next) {
> > +		/* Not actually switching mm's */
> >   		VM_WARN_ON(this_cpu_read(cpu_tlbstate.ctxs[prev_asid].ctx_id) !=
> >   			   next->context.ctx_id);
> > +		/*
> > +		 * If this races with another thread that enables lam, 'new_lam'
> > +		 * might not match 'prev_lam'.
> > +		 */
> > +
> 
> Indeed.
> 
> >   		/*
> >   		 * Even in lazy TLB mode, the CPU should stay set in the
> >   		 * mm_cpumask. The TLB shootdown code can figure out from
> > @@ -622,15 +635,16 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
> >   		barrier();
> >   	}
> 
> > @@ -691,6 +705,10 @@ void initialize_tlbstate_and_flush(void)
> >   	/* Assert that CR3 already references the right mm. */
> >   	WARN_ON((cr3 & CR3_ADDR_MASK) != __pa(mm->pgd));
> > +	/* LAM expected to be disabled in CR3 and init_mm */
> > +	WARN_ON(cr3 & (X86_CR3_LAM_U48 | X86_CR3_LAM_U57));
> > +	WARN_ON(mm_lam_cr3_mask(&init_mm));
> > +
> 
> I think the callers all have init_mm selected, but the rest of this function
> is not really written with this assumption.  (But it does force ASID 0,
> which is at least a bizarre thing to do for non-init-mm.)

Hm. It uses tlb_gen of init_mm, so I assumed &init_mm == mm, but yeah it
is not strictly correct.

> What's the purpose of this warning?  I'm okay with keeping it, but maybe
> also add a warning that fires if mm != &init_mm.

Just to make sure we are in sane state. I can drop init_mm reference if it
helps.

The fixup based on your feedback:

diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
index 1ab7ecf61659..6f5b58a5f951 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -94,7 +94,7 @@ static inline void switch_ldt(struct mm_struct *prev, struct mm_struct *next)
 #ifdef CONFIG_X86_64
 static inline unsigned long mm_lam_cr3_mask(struct mm_struct *mm)
 {
-	return mm->context.lam_cr3_mask;
+	return READ_ONCE(mm->context.lam_cr3_mask);
 }
 
 static inline void dup_lam(struct mm_struct *oldmm, struct mm_struct *mm)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 4380776b3c61..ab66a48f38ce 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -496,7 +496,6 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
 {
 	struct mm_struct *real_prev = this_cpu_read(cpu_tlbstate.loaded_mm);
 	u16 prev_asid = this_cpu_read(cpu_tlbstate.loaded_mm_asid);
-	unsigned long prev_lam = tlbstate_lam_cr3_mask();
 	unsigned long new_lam = mm_lam_cr3_mask(next);
 	bool was_lazy = this_cpu_read(cpu_tlbstate_shared.is_lazy);
 	unsigned cpu = smp_processor_id();
@@ -527,7 +526,8 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
 	 * isn't free.
 	 */
 #ifdef CONFIG_DEBUG_VM
-	if (WARN_ON_ONCE(__read_cr3() != build_cr3(real_prev->pgd, prev_asid, prev_lam))) {
+	if (WARN_ON_ONCE(__read_cr3() != build_cr3(real_prev->pgd, prev_asid,
+						   tlbstate_lam_cr3_mask()))) {
 		/*
 		 * If we were to BUG here, we'd be very likely to kill
 		 * the system so hard that we don't see the call trace.
@@ -565,7 +565,7 @@ void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,
 
 		/*
 		 * If this races with another thread that enables lam, 'new_lam'
-		 * might not match 'prev_lam'.
+		 * might not match tlbstate_lam_cr3_mask().
 		 */
 
 		/*
@@ -705,9 +705,9 @@ void initialize_tlbstate_and_flush(void)
 	/* Assert that CR3 already references the right mm. */
 	WARN_ON((cr3 & CR3_ADDR_MASK) != __pa(mm->pgd));
 
-	/* LAM expected to be disabled in CR3 and init_mm */
+	/* LAM expected to be disabled */
 	WARN_ON(cr3 & (X86_CR3_LAM_U48 | X86_CR3_LAM_U57));
-	WARN_ON(mm_lam_cr3_mask(&init_mm));
+	WARN_ON(mm_lam_cr3_mask(mm));
 
 	/*
 	 * Assert that CR4.PCIDE is set if needed.  (CR4.PCIDE initialization
-- 
  Kiryl Shutsemau / Kirill A. Shutemov


  reply	other threads:[~2022-11-09  9:18 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25  0:17 [PATCHv11 00/16] Linear Address Masking enabling Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 01/16] x86/mm: Fix CR3_ADDR_MASK Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 02/16] x86: CPUID and CR3/CR4 flags for Linear Address Masking Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 03/16] mm: Pass down mm_struct to untagged_addr() Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 04/16] x86/mm: Handle LAM on context switch Kirill A. Shutemov
2022-11-07 14:58   ` Andy Lutomirski
2022-11-07 17:14     ` Kirill A. Shutemov
2022-11-07 18:02       ` Dave Hansen
2022-11-07 21:35         ` [PATCHv11.1 " Kirill A. Shutemov
2022-11-09  3:54           ` Andy Lutomirski
2022-11-09  9:17             ` kirill [this message]
2022-10-25  0:17 ` [PATCHv11 05/16] x86/uaccess: Provide untagged_addr() and remove tags before address check Kirill A. Shutemov
2022-11-07 14:50   ` Andy Lutomirski
2022-11-07 17:33     ` Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 06/16] KVM: Serialize tagged address check against tagging enabling Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 07/16] x86/mm: Provide arch_prctl() interface for LAM Kirill A. Shutemov
2022-11-07 21:37   ` [PATCHv11.1 " Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 08/16] x86/mm: Reduce untagged_addr() overhead until the first LAM user Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 09/16] mm: Expose untagging mask in /proc/$PID/status Kirill A. Shutemov
2022-10-28 14:02   ` Catalin Marinas
2022-10-25  0:17 ` [PATCHv11 10/16] iommu/sva: Replace pasid_valid() helper with mm_valid_pasid() Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 11/16] x86/mm, iommu/sva: Make LAM and SVA mutually exclusive Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 12/16] selftests/x86/lam: Add malloc and tag-bits test cases for linear-address masking Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 13/16] selftests/x86/lam: Add mmap and SYSCALL " Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 14/16] selftests/x86/lam: Add io_uring " Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 15/16] selftests/x86/lam: Add inherit " Kirill A. Shutemov
2022-10-25  0:17 ` [PATCHv11 16/16] selftests/x86/lam: Add ARCH_FORCE_TAGGED_SVA " Kirill A. Shutemov
2022-11-07 11:25 ` [PATCHv11 00/16] Linear Address Masking enabling Kirill A. Shutemov
2022-11-07 14:59 ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221109091742.tpqxho5kvdmrto3r@box.shutemov.name \
    --to=kirill@shutemov.name \
    --cc=ak@linux.intel.com \
    --cc=andreyknvl@gmail.com \
    --cc=ashok.raj@intel.com \
    --cc=bharata@amd.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hjl.tools@gmail.com \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=kcc@google.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=ryabinin.a.a@gmail.com \
    --cc=tarasmadan@google.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox