[<prev] [next>] [day] [month] [year] [list]
Message-Id: <1424267291-10495-1-git-send-email-bigeasy@linutronix.de>
Date: Wed, 18 Feb 2015 14:48:11 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: linux-rt-users@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, tglx@...utronix.de,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: [PATCH RT] arm/futex: disable preemption during futex_atomic_cmpxchg_inatomic()
The ARM UP implementation of futex_atomic_cmpxchg_inatomic() assumes that
pagefault_disable() inherits a preempt disabled section. This assumtion
is true for mainline but -RT reverts this and allows preemption in
pagefault disabled regions.
The code sequence of futex_atomic_cmpxchg_inatomic():
| x = *futex;
| if (x == oldval)
| *futex = newval;
The problem occurs if the code is preempted after reading the futex value or
after comparing it with x. While preempted, the futex owner has to be
scheduled which then releases the lock (in userland because it has no waiter
yet). Once the code is back on the CPU, it overwrites the futex value
with with the old PID and the waiter bit set.
The workaround is to explicit disable code preemption to avoid the
described race window.
Debugged-by: Thomas Gleixner <tglx@...utronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
---
arch/arm/include/asm/futex.h | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -93,6 +93,8 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
+ preempt_disable_rt();
+
__asm__ __volatile__("@futex_atomic_cmpxchg_inatomic\n"
"1: " TUSER(ldr) " %1, [%4]\n"
" teq %1, %2\n"
@@ -104,6 +106,8 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
: "cc", "memory");
*uval = val;
+
+ preempt_enable_rt();
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists