On Sun, Jan 31, 2016 at 8:28 AM, Stas Sergeev <stsp@xxxxxxx> wrote: > > linux implements the sigaltstack() in a way that makes it impossible to > use with swapcontext(). Per the man page, sigaltstack is allowed to return > EPERM if the process is altering its sigaltstack while running on > sigaltstack. > This is likely needed to consistently return oss->ss_flags, that indicates > whether the process is being on sigaltstack or not. > Unfortunately, linux takes that permission to return EPERM too literally: > it returns EPERM even if you don't want to change to another sigaltstack, > but only want to temporarily disable sigaltstack with SS_DISABLE. > You can't use swapcontext() without disabling sigaltstack first, or the > stack will be re-used and overwritten by a subsequent signal. > > With this patch, disabling sigaltstack inside a signal handler became > possible, and the swapcontext() can then be used safely. After switching > back to the sighandler, the app can re-enable the sigatlstack. > The oss->ss_flags will correctly indicate the current use of sigaltstack, > even if it is temporarily disabled. Any attempt to modify the sigaltstack > (rather than to disable or re-enable it) within the sighandler, will still > be punished with EPERM as suggested by POSIX. This seems considerably more complicated than my previous proposal to add an SS_FORCE flag to say "I know what I'm doing. Ignore POSIX and let me change the sigaltstack configuration even if it's in use". What's the advantage? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
