Messages in this thread | | | Subject | Re: sigaltstack breaks swapcontext() | From | Stas Sergeev <> | Date | Sat, 9 Jan 2016 02:40:03 +0300 |
| |
09.01.2016 02:24, Andy Lutomirski пишет: > On Fri, Jan 8, 2016 at 5:49 AM, Stas Sergeev <stsp@list.ru> wrote: >> 06.01.2016 21:05, Andy Lutomirski пишет: >>> On Wed, Jan 6, 2016 at 7:45 AM, Stas Sergeev <stsp@list.ru> wrote: >>> >>>> Hello. >>>> >>>> swapcontext() can be used with signal handlers, >>>> it swaps the signal masks together with the other >>>> parts of the context. >>>> Unfortunately, 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 disable sigaltstack with SS_DISABLE. >>>> To my reading of a man page, this is not a desired >>>> behaviour. Moreover, you can't use swapcontext() >>>> without disabling sigaltstack first, or the stack will >>>> be re-used and overwritten by a subsequent signal. >>>> >>> The EPERM thing is probably also to preserve the behavior that nested >>> SA_ONSTACK signals are supposed to work. (Of course, the kernel gets >>> this a bit wrong because it forgets to check ss in addition to sp. >>> That would be relatively straightforward to fix.) >> I don't think it needs a fix: in 64bit mode SS doesn't matter, and >> in 32bit mode the SS is properly restored in a sighandler, so no >> one can run sigaltstack() with non-flat SS (unless the DOS code >> itself does this, which it does not). > It's not sigaltstack that I'm thinking about. It's signal delivery. > If you end up in DOS mode with SP coincidentally pointing to the > sigaltstack (but with different SS so it's not really the > sigaltstack), then the signal delivery will malfunction. Ah, sounds like a real bug then! Though if bitness differ (64bit mode and signal comes from 32bit code), there is probably no need to check anything and just switch the stack.
| |