Re: [PATCH v4 0/2] make sigaltstack() compatible with swapcontext()

[Szabolcs Nagy <nsz@port70.net>]

* Stas Sergeev <stsp@list.ru> [2016-03-01 00:29:03 +0300]:
> The following patches make it possible to use swapcontext()
> in a sighandler that works on sigaltstack.

i don't think that's possible, the (obsolete) userspace
*context functions cannot operate on kernel provided
ucontext_t structs, so they are not usable in signal
handlers.

at least not on most target archs.

so i don't understand how the tests can work portably.

> The approach is inspired by Andy Lutomirski's suggestion that
> sigaltstack should disarm itself after saving into uc_stack:
> https://lkml.org/lkml/2016/2/1/594
> 
> I add the SS_AUTODISARM flag that does exactly that.
> On sighandler exit, the sigaltstack is restored from uc_stack.
> Another possible name could be SS_ONESHOT, but, since it gets
> always re-enabled, I choose SS_AUTODISARM.
> 
> [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag
> 	This patch implements SS_AUTODISARM flag
> [PATCH 2/2] selftests: Add test for sigaltstack(SS_AUTODISARM)
> 	This patch adds the selftest code for new functionality
> 
> CC: linux-kernel@vger.kernel.org
> CC: linux-api@vger.kernel.org
> CC: Andy Lutomirski <luto@amacapital.net>
> CC: Oleg Nesterov <oleg@redhat.com>
> CC: Shuah Khan <shuahkh@osg.samsung.com>
> 
> Diffstat:
>  include/linux/sched.h                        |    8 +
>  include/linux/signal.h                       |    4 
>  include/uapi/linux/signal.h                  |    3 
>  kernel/fork.c                                |    2 
>  kernel/signal.c                              |   23 ++--
>  tools/testing/selftests/Makefile             |    1 
>  tools/testing/selftests/sigaltstack/Makefile |    8 +
>  tools/testing/selftests/sigaltstack/sas.c    |  151 +++++++++++++++++++++++++++
>  8 files changed, 187 insertions(+), 13 deletions(-)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-api" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html