On Fri, Jan 8, 2016 at 5:49 AM, Stas Sergeev <stsp@xxxxxxx> wrote:Ah, sounds like a real bug then!
06.01.2016 21:05, Andy Lutomirski ÐÐÑÐÑ:It's not sigaltstack that I'm thinking about. It's signal delivery.
On Wed, Jan 6, 2016 at 7:45 AM, Stas Sergeev <stsp@xxxxxxx> wrote:I don't think it needs a fix: in 64bit mode SS doesn't matter, and
Hello.The EPERM thing is probably also to preserve the behavior that nested
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
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.
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.)
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).
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.