All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Chris Wright <chrisw@sous-sol.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	zach@vmware.com, torvalds@osdl.org
Subject: Re: [PATCH] x86/PAE: Fix pte_clear for the >4GB RAM case
Date: Fri, 28 Apr 2006 08:29:28 +0200	[thread overview]
Message-ID: <200604280829.29164.ak@suse.de> (raw)
In-Reply-To: <20060428062704.GH2909@sorel.sous-sol.org>

On Friday 28 April 2006 08:27, Chris Wright wrote:
> * Andi Kleen (ak@suse.de) wrote:
> > On Friday 28 April 2006 07:23, Chris Wright wrote:
> > > * Andi Kleen (ak@suse.de) wrote:
> > > > > +static inline void pmd_clear(pmd_t *pmd)
> > > > > +{
> > > > > +	u32 *tmp = (u32 *)pmd;
> > > > > +	*tmp = 0;
> > > > > +	smp_wmb();
> > > > > +	*(tmp + 1) = 0;
> > > > > +}
> > > > 
> > > > I think that's still wrong - it should be wmb() not smp_wmb because this
> > > > problem can happen on a UP kernel already.
> > > 
> > > I thought the barrier is to keep compiler from reordering not processor.
> > 
> > Yes, but with smp_wmb() it will go away on UP. And even on UP the
> > CPU is free to speculate.
> 
> I must be confused.  Doesn't that become a barrier() on UP?

No it was me who was confused sorry. Somehow i thought it was defined
away for !SMP

(which would make sense because why would you want a compile barrier
for a barrier that is only needed on SMP?) 

-Andi

  reply	other threads:[~2006-04-28  6:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200604272001.k3RK1dmX007637@hera.kernel.org>
2006-04-28  5:18 ` [PATCH] x86/PAE: Fix pte_clear for the >4GB RAM case Andi Kleen
2006-04-28  5:23   ` Chris Wright
2006-04-28  6:08     ` Andi Kleen
2006-04-28  6:27       ` Chris Wright
2006-04-28  6:29         ` Andi Kleen [this message]
2006-04-28  7:20           ` Nick Piggin
2006-04-28 14:54           ` Linus Torvalds

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=200604280829.29164.ak@suse.de \
    --to=ak@suse.de \
    --cc=chrisw@sous-sol.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    --cc=zach@vmware.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.