From: Waiman Long <waiman.long@hp.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
jejb@parisc-linux.org, deller@gmx.de,
John David Anglin <dave.anglin@bell.net>,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
chegu_vinod@hp.com, paulmck@linux.vnet.ibm.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, 02 Jun 2014 10:14:58 -0400 [thread overview]
Message-ID: <538C86E2.1070806@hp.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1406011342470.20831@file01.intranet.prod.int.rdu2.redhat.com>
On 06/01/2014 01:53 PM, Mikulas Patocka wrote:
> The code in kernel/locking/mcs_spinlock.c is broken.
The osq_lock and osq_unlock functions aren't the only ones that need to
be changed, the mcs_spin_lock and mcs_spin_unlock have exactly the same
problem. There aren't certainly problems in other places as well.
> PA-RISC doesn't have xchg or cmpxchg atomic instructions like other
> processors. It only has ldcw and ldcd instructions that load a word (or
> doubleword) from memory and atomically store zero at the same location.
> These instructions can only be used to implement spinlocks, direct
> implementation of other atomic operations is impossible.
>
> Consequently, Linux xchg and cmpxchg functions are implemented in such a
> way that they hash the address, use the hash to index a spinlock, take the
> spinlock, perform the xchg or cmpxchg operation non-atomically and drop
> the spinlock.
>
> 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.
>
> This patch fixes the bug by introducing a new type atomic_pointer_t
> (backed by atomic_long_t) and replacing the offending pointer with it.
> atomic_long_set takes the hashed spinlock, so it avoids the race
> condition.
I believe the mixing of cmpxchg/xchg and ACCESS_ONCE() is fairly common
in the kernel, it will be an additional burden on the kernel developers
to make sure that this kind of breakage won't happen. We also need clear
documentation somewhere to document this kind of architecture specific
behavior, maybe in the memory-barrier.txt.
> Index: linux-3.15-rc7/kernel/locking/mcs_spinlock.h
> ===================================================================
> --- linux-3.15-rc7.orig/kernel/locking/mcs_spinlock.h 2014-05-31 19:01:01.000000000 +0200
> +++ linux-3.15-rc7/kernel/locking/mcs_spinlock.h 2014-06-01 14:17:49.000000000 +0200
> @@ -13,6 +13,7 @@
> #define __LINUX_MCS_SPINLOCK_H
>
> #include<asm/mcs_spinlock.h>
> +#include<linux/atomic.h>
>
> struct mcs_spinlock {
> struct mcs_spinlock *next;
> @@ -119,7 +120,8 @@ void mcs_spin_unlock(struct mcs_spinlock
> */
>
> struct optimistic_spin_queue {
> - struct optimistic_spin_queue *next, *prev;
> + atomic_pointer_t next;
> + struct optimistic_spin_queue *prev;
> int locked; /* 1 if lock acquired */
> };
Is there a way to do it without changing the pointer type? It will make
the code harder to read and understand.
-Longman
next prev parent reply other threads:[~2014-06-02 14:15 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
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 [this message]
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=538C86E2.1070806@hp.com \
--to=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=paulmck@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox