public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Benjamin LaHaise <bcrl@kvack.org>, Ingo Molnar <mingo@elte.hu>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: What protects cpu_tlbstate?
Date: Thu, 5 Apr 2007 22:28:36 +0200	[thread overview]
Message-ID: <200704052228.36590.ak@suse.de> (raw)
In-Reply-To: <4615518A.4070003@goop.org>

On Thursday 05 April 2007 21:44:10 Jeremy Fitzhardinge wrote:
> Hi,
> 
> What protects the cpu_tlbstate?  I see in i386/kernel/smp.c that its
> always used in a non-preemptable area, but what prevents races with
> interrupts?  For example, what prevents leave_mm() called via the
> flush_tlb_all IPI from racing with, say, enter_lazy_tlb?  Couldn't a
> race leave cpu_tlbstate in an inconsistent state?
> 
> Or does it simply not matter?  But if that were true, it seems to me
> that there should be at least some barriers or something to make sure
> the final state is consistent.

The interrupts can only happen when the other CPU is already lazy
and enter_lazy_tlb would be a nop then.  The flushers itself are
synchronized by the page_table_lock or the mm semaphore.

Against switch_mm it tries to protect with ordering.

wmb()s are not needed on x86 (ok minus errata on ppro and
VIA magic mode but which is UP only). That would leave some rmb()s,
but I don't see any place they would be needed. 

-Andi


  reply	other threads:[~2007-04-05 20:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-05 19:44 What protects cpu_tlbstate? Jeremy Fitzhardinge
2007-04-05 20:28 ` Andi Kleen [this message]
2007-04-05 21:00   ` Jeremy Fitzhardinge
2007-04-05 21:03     ` Andi Kleen
2007-04-05 21:08       ` Jeremy Fitzhardinge

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=200704052228.36590.ak@suse.de \
    --to=ak@suse.de \
    --cc=bcrl@kvack.org \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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