Messages in this thread | | | Date | Fri, 9 Nov 2007 12:22:08 -0800 | From | Andrew Morton <> | Subject | Re: Fix for sparc64 cpu hangs. |
| |
On Tue, 06 Nov 2007 21:13:56 -0800 (PST) David Miller <davem@davemloft.net> wrote:
> From: David Miller <davem@davemloft.net> > Date: Tue, 06 Nov 2007 20:34:33 -0800 (PST) > > > [FUTEX]: Fix address computation in compat code. > > Sorry, I just noticed there is a second handle_futex_death() > call in compat_exit_robust_list() which has the same > address computation bug. > > Here is an updated patch: > > [FUTEX]: Fix address computation in compat code. > > compat_exit_robust_list() computes a pointer to the > futex entry in userspace as follows: > > (void __user *)entry + futex_offset > > 'entry' is a 'struct robust_list __user *', and > 'futex_offset' is a 'compat_long_t' (typically a 's32'). > > Things explode if the 32-bit sign bit is set in futex_offset. > > Type promotion sign extends futex_offset to a 64-bit value before > adding it to 'entry'. > > This triggered a problem on sparc64 running 32-bit applications which > would lock up a cpu looping forever in the fault handling for the > userspace load in handle_futex_death(). > > Compat userspace runs with address masking (wherein the cpu zeros out > the top 32-bits of every effective address given to a memory operation > instruction) so the sparc64 fault handler accounts for this by > zero'ing out the top 32-bits of the fault address too. > > Since the kernel properly uses the compat_uptr interfaces, kernel side > accesses to compat userspace work too since they will only use > addresses with the top 32-bit clear. > > Because of this compat futex layer bug we get into the following loop > when executing the get_user() load near the top of handle_futex_death(): > > 1) load from address '0xfffffffff7f16bd8', FAULT > 2) fault handler clears upper 32-bits, processes fault > for address '0xf7f16bd8' which succeeds > 3) goto #1 > > I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto > for their tireless efforts helping me track down this bug. >
I tagged this as needed-in-2.6.23.x. Please let me know if that is not appropriate.
- 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/
| |