| Message ID | 1345345030-22211-75-git-send-email-andi@firstfloor.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 08/18/2012 07:57 PM, Andi Kleen wrote: > From: Andi Kleen <ak@linux.intel.com> > > On a 32bit build gcc 4.7 with LTO decides to clobber the 6th argument on the > stack. Unfortunately this corrupts the user EBP and leads to later crashes. > For now mark do_futex noinline to prevent this. > > I wish there was a generic way to handle this. Seems like a ticking time > bomb problem. > There is a generic way to handle this. This is actually a bug in Linux that has been known for at least 15 years and which we keep hacking around. The right thing to do is to change head_32.S to not violate the i386 ABI. Arguments pushed (by value) on the stack are property of the callee, that is, they are volatile, so the hack of making them do double duty as both being saved and passed as arguments is just plain bogus. The problem is that it works "just well enough" that people (including myself) keep hacking around it with hacks like this, with assembly macros, and whatnot instead of fixing the root cause. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/22/2012 05:17 PM, H. Peter Anvin wrote: > On 08/18/2012 07:57 PM, Andi Kleen wrote: >> From: Andi Kleen <ak@linux.intel.com> >> >> On a 32bit build gcc 4.7 with LTO decides to clobber the 6th argument on the >> stack. Unfortunately this corrupts the user EBP and leads to later crashes. >> For now mark do_futex noinline to prevent this. >> >> I wish there was a generic way to handle this. Seems like a ticking time >> bomb problem. >> > > There is a generic way to handle this. This is actually a bug in Linux > that has been known for at least 15 years and which we keep hacking around. > > The right thing to do is to change head_32.S to not violate the i386 > ABI. Arguments pushed (by value) on the stack are property of the > callee, that is, they are volatile, so the hack of making them do double > duty as both being saved and passed as arguments is just plain bogus. > The problem is that it works "just well enough" that people (including > myself) keep hacking around it with hacks like this, with assembly > macros, and whatnot instead of fixing the root cause. > > -hpa > Just a clarification (Andi knows this, I'm sure, but others might not): this wasn't done the way it is for no reason; back when Linus originally wrote the code, i386 passed *all* arguments on the stack, and we still do that for "asmlinkage" functions on i386. Since gcc back then rarely if ever mucked with the stack arguments, it made sense to make them "double duty." Fixing this really should entail changing the invocation of system calls on i386 to use the regparm convention, which means we only need to push three arguments twice, rather than six. -hpa
> The right thing to do is to change head_32.S to not violate the i386 > ABI. Arguments pushed (by value) on the stack are property of the > callee, that is, they are volatile, so the hack of making them do double > duty as both being saved and passed as arguments is just plain bogus. > The problem is that it works "just well enough" that people (including > myself) keep hacking around it with hacks like this, with assembly > macros, and whatnot instead of fixing the root cause. How about just use register arguments for the first three arguments. This should work for the syscalls at least (may be too risky for all other asm entry points) And for syscalls with more than three generate a stub that saves on the stack explicitely. This could be done using the new fancy SYSCALL definition macros (except that arch/x86 would need to start using them too in its own code) Or is there some subtle reason with syscall restart and updated args that prevents it? Perhaps newer gcc can do regparm(X), X > 3 too, may be worth trying. Don't have time to look into this currently though. -Andi
On 08/22/2012 07:29 PM, Andi Kleen wrote: > How about just use register arguments for the first three arguments. > This should work for the syscalls at least (may be too risky for all > other asm entry points) Well, it's just an effort to convert each one in turn... > And for syscalls with more than three generate a stub that saves on the stack > explicitely. This could be done using the new fancy SYSCALL definition macros > (except that arch/x86 would need to start using them too in its own code) I don't think there is any point. Just push the six potential arguments to the stack and be done with it. > Or is there some subtle reason with syscall restart and updated args > that prevents it? > > Perhaps newer gcc can do regparm(X), X > 3 too, may be worth trying. No, there is no such ABI defined. > Don't have time to look into this currently though. Always the problem. -hpa
diff --git a/kernel/futex.c b/kernel/futex.c index 3717e7b..48b5a07 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -2620,7 +2620,7 @@ void exit_robust_list(struct task_struct *curr) curr, pip); } -long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout, +noinline long do_futex(u32 __user *uaddr, int op, u32 val, ktime_t *timeout, u32 __user *uaddr2, u32 val2, u32 val3) { int cmd = op & FUTEX_CMD_MASK;