* debian/patches/series/7-extra: Add s390-kernel-futex-barrier.patch.

* debian/patches/s390-kernel-futex-barrier.patch: Add.

svn path=/dists/sid/linux-2.6/; revision=7236

2 files changed, 134 insertions, 0 deletions

diff --git a/debian/patches/s390-kernel-futex-barrier.patch b/debian/patches/s390-kernel-futex-barrier.patch
new file mode 100644
index 000000000000..54cf6313a663
--- /dev/null
+++ b/debian/patches/s390-kernel-futex-barrier.patch
@@ -0,0 +1,133 @@
+From: Christian Borntraeger <borntrae@de.ibm.com>
+
+This patch adds a barrier() in futex unqueue_me to avoid aliasing of two 
+pointers.
+
+On my s390x system I saw the following oops:
+
+Unable to handle kernel pointer dereference at virtual kernel address 
+0000000000000000
+Oops: 0004 [#1]
+CPU:    0    Not tainted
+Process mytool (pid: 13613, task: 000000003ecb6ac0, ksp: 00000000366bdbd8)
+Krnl PSW : 0704d00180000000 00000000003c9ac2 (_spin_lock+0xe/0x30)
+Krnl GPRS: 00000000ffffffff 000000003ecb6ac0 0000000000000000 0700000000000000
+           0000000000000000 0000000000000000 000001fe00002028 00000000000c091f
+           000001fe00002054 000001fe00002054 0000000000000000 00000000366bddc0
+           00000000005ef8c0 00000000003d00e8 0000000000144f91 00000000366bdcb8
+Krnl Code: ba 4e 20 00 12 44 b9 16 00 3e a7 84 00 08 e3 e0 f0 88 00 04
+Call Trace:
+([<0000000000144f90>] unqueue_me+0x40/0xe4)
+ [<0000000000145a0c>] do_futex+0x33c/0xc40
+ [<000000000014643e>] sys_futex+0x12e/0x144
+ [<000000000010bb00>] sysc_noemu+0x10/0x16
+ [<000002000003741c>] 0x2000003741c
+
+
+
+The code in question is:
+
+static int unqueue_me(struct futex_q *q)
+{
+        int ret = 0;
+        spinlock_t *lock_ptr;
+
+        /* In the common case we don't take the spinlock, which is nice. */
+ retry:
+        lock_ptr = q->lock_ptr;
+        if (lock_ptr != 0) {
+                spin_lock(lock_ptr);                
+		/*
+                 * q->lock_ptr can change between reading it and
+                 * spin_lock(), causing us to take the wrong lock.  This
+                 * corrects the race condition.
+[...]
+
+
+and my compiler (gcc 4.1.0) makes the following out of it:
+
+00000000000003c8 <unqueue_me>:
+     3c8:       eb bf f0 70 00 24       stmg    %r11,%r15,112(%r15)
+     3ce:       c0 d0 00 00 00 00       larl    %r13,3ce <unqueue_me+0x6>
+                        3d0: R_390_PC32DBL      .rodata+0x2a
+     3d4:       a7 f1 1e 00             tml     %r15,7680
+     3d8:       a7 84 00 01             je      3da <unqueue_me+0x12>
+     3dc:       b9 04 00 ef             lgr     %r14,%r15
+     3e0:       a7 fb ff d0             aghi    %r15,-48
+     3e4:       b9 04 00 b2             lgr     %r11,%r2
+     3e8:       e3 e0 f0 98 00 24       stg     %r14,152(%r15)
+     3ee:       e3 c0 b0 28 00 04       lg      %r12,40(%r11) 
+		/* write q->lock_ptr in r12 */
+     3f4:       b9 02 00 cc             ltgr    %r12,%r12
+     3f8:       a7 84 00 4b             je      48e <unqueue_me+0xc6>
+		/* if r12 is zero then jump over the code.... */
+     3fc:       e3 20 b0 28 00 04       lg      %r2,40(%r11)
+		/* write q->lock_ptr in r2 */
+     402:       c0 e5 00 00 00 00       brasl   %r14,402 <unqueue_me+0x3a>
+                        404: R_390_PC32DBL      _spin_lock+0x2
+		/* use r2 as parameter for spin_lock */
+
+So the code becomes more or less:
+if (q->lock_ptr != 0) spin_lock(q->lock_ptr)
+instead of
+if (lock_ptr != 0) spin_lock(lock_ptr)
+
+Which caused the oops from above.
+After adding a barrier gcc creates code without this problem:
+[...] (the same)
+     3ee:       e3 c0 b0 28 00 04       lg      %r12,40(%r11)
+     3f4:       b9 02 00 cc             ltgr    %r12,%r12
+     3f8:       b9 04 00 2c             lgr     %r2,%r12
+     3fc:       a7 84 00 48             je      48c <unqueue_me+0xc4>
+     400:       c0 e5 00 00 00 00       brasl   %r14,400 <unqueue_me+0x38>
+                        402: R_390_PC32DBL      _spin_lock+0x2
+
+
+
+As a general note, this code of unqueue_me seems a bit fishy. The retry logic 
+of unqueue_me only works if we can guarantee, that the original value of 
+q->lock_ptr is always a spinlock (Otherwise we overwrite kernel memory). We 
+know that q->lock_ptr can change. I dont know what happens with the original 
+spinlock, as I am not an expert with the futex code. 
+
+CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
+CC: Rusty Russell <rusty@rustcorp.com.au>
+CC: Ingo Molnar <mingo@redhat.com>
+CC: Thomas Gleixner <tglx@timesys.com>
+Signed-off-by: Christian Borntraeger <borntrae@de.ibm.com>
+---
+ 
+futex.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+---
+diff --git a/kernel/futex.c b/kernel/futex.c
+index cf0c8e2..01aa87c 100644
+--- a/kernel/futex.c
++++ b/kernel/futex.c
+@@ -930,6 +930,7 @@ static int unqueue_me(struct futex_q *q)
+ 	/* In the common case we don't take the spinlock, which is nice. */
+  retry:
+ 	lock_ptr = q->lock_ptr;
++	barrier();
+ 	if (lock_ptr != 0) {
+ 		spin_lock(lock_ptr);
+ 		/*
+
+
+
+
+-- 
+Mit freundlichen Grüßen / Best Regards
+
+Christian Borntraeger
+Linux Software Engineer zSeries Linux & Virtualization
+
+
+
+-
+To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at  http://vger.kernel.org/majordomo-info.html
+Please read the FAQ at  http://www.tux.org/lkml/
+
diff --git a/debian/patches/series/7-extra b/debian/patches/series/7-extra
index 50ad73f71f8e..2d4f73d9c612 100644
--- a/debian/patches/series/7-extra
+++ b/debian/patches/series/7-extra
@@ -4,3 +4,4 @@
 + mips-tulip-2700.patch mipsel
 + vserver-version.patch *_vserver *_xen-vserver
 + vserver-vs2.0.2-rc29.patch *_vserver *_xen-vserver
++ s390-kernel-futex-barrier.patch s390