I don't think there's problem, unless I'm missing something.
> The problem IMO is that the signal handling code stores a processor context
> on the user-mode stack frame which is active while
> the signal handler is running.
User context (defined by 'regs') is stored onto the user stack.
However, when context is restored, certain checks are done, including
making sure that the segment registers cs and ss are their user mode
versions (or'd with 3), and the processor flags are non-privileged.
This means that when the kernel does eventually return to user space,
if the user has pointed the EIP address at panic(), by the time we
jump there the processor will not be in a privileged mode, and panic()
won't do anything (you'll probably end up with a page fault caused by
the processor fetching instructions from kernel space).
However, that said, I don't know x86 in depth (I'm the ARM guy), so
don't take this as gospel, but should be sufficient to point you in
the right direction. (check the segment registers, check the eflags
register, hell, try it out for real and see what happens)!
-- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html- 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/