From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
John David Anglin <dave.anglin@bell.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
jejb@parisc-linux.org, deller@gmx.de,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
chegu_vinod@hp.com, Waiman.Long@hp.com, tglx@linutronix.de,
riel@redhat.com, akpm@linux-foundation.org, davidlohr@hp.com,
hpa@zytor.com, andi@firstfloor.org, aswin@hp.com,
scott.norton@hp.com, Jason Low <jason.low2@hp.com>
Subject: Re: [PATCH] fix a race condition in cancelable mcs spinlocks
Date: Mon, 2 Jun 2014 06:24:54 -0700 [thread overview]
Message-ID: <20140602132454.GO22231@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1406020503000.17105@file01.intranet.prod.int.rdu2.redhat.com>
On Mon, Jun 02, 2014 at 05:19:39AM -0400, Mikulas Patocka wrote:
>
>
> On Sun, 1 Jun 2014, Peter Zijlstra wrote:
>
> > On Sun, Jun 01, 2014 at 04:46:26PM -0400, John David Anglin wrote:
> > > On 1-Jun-14, at 3:20 PM, Peter Zijlstra wrote:
> > >
> > > >>If you write to some variable with ACCESS_ONCE and use cmpxchg or xchg
> > > >>at
> > > >>the same time, you break it. ACCESS_ONCE doesn't take the hashed
> > > >>spinlock,
> > > >>so, in this case, cmpxchg or xchg isn't really atomic at all.
> > > >
> > > >And this is really the first place in the kernel that breaks like this?
> > > >I've been using xchg() and cmpxchg() without such consideration for
> > > >quite a while.
> > >
> > > I believe Mikulas is correct. Even in a controlled situation where a
> > > cmpxchg operation
> > > is used to implement pthread_spin_lock() in userspace, we found recently
> > > that the lock
> > > must be released with a cmpxchg operation and not a simple write on SMP
> > > systems.
> > > There is a race in the cache operations or instruction ordering that's not
> > > present with
> > > the ldcw instruction.
> >
> > Oh, I'm not arguing that. He's quite right that its broken, but this
> > form of atomic ops is also quite insane and unusual. Most sane machines
> > don't have this problem.
> >
> > My main concern is how are we going to avoid breaking parisc (and I
> > think sparc32, which is similarly retarded) in the future; we should
> > invest in machinery to find and detect these things.
>
> Grep the kernel for "\<xchg\>" and "\<cmpxchg\>" and replace them with
> atomic types and atomic access functions.
Not so good for pointers, though. Defeats type-checking, for one thing.
An example of this is use of xchg() for atomically enqueuing RCU callbacks
in kernel/rcu/tree_plugin.h.
I still like the idea of PA-RISC's compiler implementing ACCESS_ONCE()
as needed to make things work on that architecture.
Thanx, Paul
next prev parent reply other threads:[~2014-06-02 13:24 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-01 17:53 [PATCH] fix a race condition in cancelable mcs spinlocks Mikulas Patocka
2014-06-01 19:20 ` Peter Zijlstra
2014-06-01 20:46 ` John David Anglin
2014-06-01 21:30 ` Peter Zijlstra
2014-06-01 21:46 ` Paul E. McKenney
2014-06-02 9:19 ` Mikulas Patocka
2014-06-02 13:24 ` Paul E. McKenney [this message]
2014-06-02 15:57 ` Mikulas Patocka
2014-06-02 16:39 ` Paul E. McKenney
2014-06-02 19:56 ` James Bottomley
2014-06-03 7:56 ` Peter Zijlstra
2014-06-04 12:53 ` Mikulas Patocka
2014-06-02 13:58 ` Mikulas Patocka
2014-06-02 14:02 ` Mikulas Patocka
2014-06-02 15:39 ` John David Anglin
2014-06-02 10:34 ` Mikulas Patocka
2014-06-02 14:14 ` Waiman Long
2014-06-02 15:27 ` Jason Low
2014-06-02 16:00 ` [PATCH v2] introduce atomic_pointer to " Mikulas Patocka
2014-06-02 16:25 ` Peter Zijlstra
2014-06-02 16:30 ` Peter Zijlstra
2014-06-02 16:46 ` Paul E. McKenney
2014-06-02 17:33 ` Waiman Long
2014-06-02 20:05 ` Peter Zijlstra
2014-06-02 20:22 ` Linus Torvalds
2014-06-02 21:02 ` Paul E. McKenney
2014-06-02 21:12 ` Linus Torvalds
2014-06-02 22:08 ` Paul E. McKenney
2014-06-02 22:44 ` Eric Dumazet
2014-06-02 23:17 ` Paul E. McKenney
2014-06-02 23:53 ` Eric Dumazet
2014-06-03 0:28 ` Paul E. McKenney
2014-06-02 22:55 ` Linus Torvalds
2014-06-03 16:48 ` Paul E. McKenney
2014-06-03 7:54 ` Peter Zijlstra
2014-06-02 20:24 ` James Bottomley
2014-06-02 16:43 ` Paul E. McKenney
2014-06-02 17:14 ` James Bottomley
2014-06-02 17:29 ` Waiman Long
2014-06-02 17:09 ` Linus Torvalds
2014-06-02 17:12 ` Davidlohr Bueso
2014-06-02 17:42 ` Waiman Long
2014-06-02 20:46 ` Mikulas Patocka
2014-06-02 20:53 ` Linus Torvalds
2014-06-02 21:12 ` Mikulas Patocka
2014-06-03 7:36 ` Peter Zijlstra
2014-06-03 11:14 ` Mikulas Patocka
2014-06-03 13:24 ` Peter Zijlstra
2014-06-03 14:18 ` Mikulas Patocka
2014-06-03 14:07 ` Paul E. McKenney
2014-06-03 15:09 ` Peter Zijlstra
2014-06-03 15:56 ` Paul E. McKenney
2014-06-03 7:20 ` Peter Zijlstra
2014-06-02 21:03 ` Paul E. McKenney
2014-06-06 15:06 ` Peter Zijlstra
2014-06-06 15:15 ` Paul E. McKenney
2014-06-06 15:42 ` Davidlohr Bueso
2014-06-02 16:50 ` Jason Low
2014-06-02 17:03 ` Paul E. McKenney
2014-06-02 17:25 ` Waiman Long
2014-06-02 17:38 ` H. Peter Anvin
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=20140602132454.GO22231@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Waiman.Long@hp.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=aswin@hp.com \
--cc=chegu_vinod@hp.com \
--cc=dave.anglin@bell.net \
--cc=davidlohr@hp.com \
--cc=deller@gmx.de \
--cc=hpa@zytor.com \
--cc=jason.low2@hp.com \
--cc=jejb@parisc-linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=scott.norton@hp.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 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.