Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 8 Jan 2016 17:48:13 -0800 | Subject | Re: sigaltstack breaks swapcontext() |
| |
On Fri, Jan 8, 2016 at 5:43 PM, Stas Sergeev <stsp@list.ru> wrote: > 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. > > Will you take care of this one? > Looks quite dangerous for dosemu! And absolutely > undebuggable: you never know when you hit it.
I'll try to remember to tack it on to the sigcontext series.
--Andy
| |