On Sun, Jan 31, 2016 at 2:36 PM, Stas Sergeev <stsp@xxxxxxx> wrote:I simply don't understand how can we have more than one
31.01.2016 23:11, Andy Lutomirski ÐÐÑÐÑ:As long as the kernel has a concept of a programmed but disabled
On Sun, Jan 31, 2016 at 12:08 PM, Stas Sergeev <stsp@xxxxxxx> wrote:But you only get into troubles when you switch between 2
31.01.2016 22:03, Andy Lutomirski ÐÐÑÐÑ:Why is it so unrealistic? You're already using swapcontext, which
Also, consider a use case like yours but with *two* contexts that useOf course the good practice is to set the sigaltstack
their own altstack. If you go to context A, enable sigaltstack, get a
signal, temporarily disable, then swapcontext to B, which tries to
re-enable its own sigaltstack, then everything gets confusing with
your patch, because, with your patch, the kernel is only tracking one
temporarily disabled sigaltstack.
before creating the contexts. Then the above scenario
should involve switching between 2 signal handlers to get
into troubles. I think the scenario with switching between
2 signal handlers is very-very unrealistic.
means you're doing something like userspace threads (although I
imagine that one of your thread-like things is DOS, but still), and,
to me, that suggests that the kernel interface should be agnostic as
to how many thread-like thinks are alive.
_active signal handlers_, rather than between 2 normal contexts,
or between 2 normal context and 1 sighandler.
So I am probably misunderstanding the scenario you describe.
Without 2 sighandlers that are active at the same time and you
switch between them, how would you get into troubles?
You say "then swapcontext to B, which tries to re-enable its own
but there can be only one sigaltstack per thread, so I am quite
sure by re-enabling "its own sigaltstack" it will still do the right
sigaltstack, something is confused when there is more than one
user-created inactive sigaltstack.
So I don't see why you want the2 reasons:
kernel to remember about disabled altstacks at all.
If you mean every sighandler installs its own, then I thinkI don't think this is the problem because only the signal handlerWhy would there only be one per thread?
should re-enable the sigaltstack, and I don't think we really should
switch between 2 active signal handlers. And even if we did, there
can be only one sigaltstack per thread, so it will re-enable always
the right stack (there is only one).
No, its when you use SA_SIGINFO with sigaction().That's only the case if swapcontext is implemented using rt_sigreturn. Is it?ISTM it would be simpler if you did:In the real world you don't even need sigaltstack(set new altstack)
swapcontext() to context using sigaltstack
sigaltstack(set new altstack)
and then later
sigaltstack(disable, force) /* just in case. save old state, too. */
swapcontext() to context not using sigaltstack
sigaltstack(set new altstack)
because uc_stack does this for you on rt_sigreturn. It is only my
test-case that does so.
I understand. With SS_FORCE there is no temptation to emulate...which is why I suggested SS_FORCE in the first place.If it would be POSIX compliant to allow SS_DISABLE to work even if onYes, that's why I was suggesting to just remove the EPERM
the altstack even without a new flag (which is what you're
suggesting), then getting rid of the temporary in-kernel state would
considerably simplify this patch series. Just skip the -EPERM check
in the disable path.
check initially. We can still do exactly that. The only problem I
can see with removing EPERM is that it would be hard to emulate
the old behaviour if need be. For example if glibc want to return
EPERM behaviour, it will have problems doing so because oss->ss_flags
doesn't say if we are on a sigaltstack and there is no other way
to find out.