Messages in this thread | | | Date | Thu, 06 Oct 2005 11:22:11 -0400 | From | Bryan Ford <> | Subject | Re: [PATCH] x86_64 signal handling for 64-bit apps w/ mixed 32-bit code - trivial fix |
| |
On Wednesday 05 October 2005 13:38, Mika Penttilä wrote: > Bryan Ford wrote: > >The following trivial patch fixes a bug in signal handling on x86-64: the > >kernel currently fails to save and restore the CS and SS segment registers > > on user-mode signal handler dispatch/return, which makes it impossible > > for 64-bit applications to catch and handle signals properly that occur > > while running 32-bit code fragments in compatibility mode. > > > >The proposed patch doesn't affect any performance-critical paths (e.g., > >syscall or interrupt entry/exit), and merely involves a couple more moves > >to/from user space on signal frame setup and sigreturn. It also doesn't > >affect the size or shape of the sigcontext at all, since there already was > > an (unused) slot for CS, and I've assigned the convenient __pad0 field as > > a slot for SS. The existing, unused slots for FS and GS remain unused > > for now, and I don't see any urgent need to change that. The only way > > this might break an existing app is if the app tries to cons up its own > > signal frame (not generated by the kernel) and pass it to sigreturn, but > > this is presumably a no-no anyway. > > What about the opposite? Are there things that would break if the app > depends on compatibility mode signal handler?
If you're thinking about 32-bit compatibility mode apps, this patch doesn't affect them at all, because signal handling for 32-bit apps is already handled by completely separate code paths (in arch/x86_64/ia32/ia32_signal.c instead of arch/x86_64/kernel/signal.c). And note that the 32-bit ABI's signal handling code path already saves the CS and SS properly, in exactly the same way as my proposed patch does for the 64-bit ABI; my patch effectively just brings the two in line with each other.
There is already no way for a 64-bit app to register and use a compatibility-mode signal handler: the kernel's signal handling code path for the 64-bit ABI always sets up a signal handling frame assuming that the signal handler will be 64-bit, and I see no reason this should be changed. I would merely like it to be possible for a 64-bit app to run snippets of 32-bit code when it needs to, and be able to catch signals that may occur while running that 32-bit code, without immediately dying a horrible flaming death as it does now because of the kernel trying to run a 64-bit signal handler with a 32-bit code segment still loaded.
Cheers, Bryan - 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/
| |