Roland McGrath wrote:: >>> Thank you for your detailed explanation and patch. I tested your >>> patch, unfortunately it can not stop all kinds of overflow. >> [...] >>> So, the patch I posted is still needed >> thanks, i've picked up your fix for x86.git, for 2.6.25 merging. > > I just explained that not all overflows would be caught and that doing so > would violate the semantics of e.g. longjmp. I don't see how the patch > you've included now doesn't still have all those problems. I think it's > wrong. >
I am sorry, i don't understand how this is related to the semantics of e.g. longjmp. But, i am sure my patch solves all overflows. Ingo's patch can't catch the overflow which is caught by "int i[1000];" in the handler function. Do you have more idea for me? Thanks. Regards Shi Weihua By the way, I think Ingo's patch can be improved. Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]> Signed-off-by: Shi Weihua <[EMAIL PROTECTED]> --- --- linux-2.6.24-rc4-git1.orig/arch/x86/kernel/signal_32.c 2007-12-04 12:26:10.000000000 +0800 +++ linux-2.6.24-rc4-git1/arch/x86/kernel/signal_32.c 2007-12-05 11:13:56.000000000 +0800 @@ -297,8 +297,17 @@ get_sigframe(struct k_sigaction *ka, str /* This is the X/Open sanctioned signal stack switching. */ if (ka->sa.sa_flags & SA_ONSTACK) { - if (sas_ss_flags(esp) == 0) + int onstack = sas_ss_flags(esp); + if (onstack == 0) esp = current->sas_ss_sp + current->sas_ss_size; + else if(onstack == SS_ONSTACK){ + /* + * If we are on the alternate signal stack and would overflow it, don't. + * Return an always-bogus address instead so we will die with SIGSEGV. + */ + if (!likely(on_sig_stack(esp - frame_size))) + return (void __user *) -1L; + } } /* This is the legacy signal stack switching. */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/