Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Gilles Chanteperdrix wrote: > Philippe Gerum wrote: >> Gilles Chanteperdrix wrote: >>> Philippe Gerum wrote: Gilles Chanteperdrix wrote: > Hi, > > on some (all ?) platforms, we get a SIGILL when trying to emit the first > Xenomai syscall, instead of the -ENOSYS return value. This patches > handles the SIGILL by printing an error message and exiting. > This is an issue for archs that encode the syscall number into the trap opcode like ARM using the OABI, others will get -ENOSYS as expected, so this should move to the arch-specific code. >>> Actually, I get a SIGILL on ARM compiled with EABI as well. >> It seems the ARM folks decided to send SIGILL with EABI to conform to the >> OABI >> behaviour, despite they did not formally need that. Only invalid calls in the >> 9f00xx..9f07ff range are expected to return -ENOSYS. Too bad that our syscall >> marker is out of that range. >> >> Moving this >>> code to the arch dependent code looks hard, since we need to setup the >>> jump buffer in the very function which issues the syscall (Ok, we could >>> use a macro). But what would you think of a SIGILL handler which does >>> not longjmp (like Jan suggested, simply print an error message and exit, >>> even if xeno_bind_skin_opt was called) ? >>> >> Fine with me. > > Ok. Commited in trunk. Do I commit in v2.4.x branch? > Yep. Thanks. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Philippe Gerum wrote: > Gilles Chanteperdrix wrote: >> Philippe Gerum wrote: >>> Gilles Chanteperdrix wrote: Hi, on some (all ?) platforms, we get a SIGILL when trying to emit the first Xenomai syscall, instead of the -ENOSYS return value. This patches handles the SIGILL by printing an error message and exiting. >>> This is an issue for archs that encode the syscall number into the trap >>> opcode >>> like ARM using the OABI, others will get -ENOSYS as expected, so this should >>> move to the arch-specific code. >> Actually, I get a SIGILL on ARM compiled with EABI as well. > > It seems the ARM folks decided to send SIGILL with EABI to conform to the OABI > behaviour, despite they did not formally need that. Only invalid calls in the > 9f00xx..9f07ff range are expected to return -ENOSYS. Too bad that our syscall > marker is out of that range. > > Moving this >> code to the arch dependent code looks hard, since we need to setup the >> jump buffer in the very function which issues the syscall (Ok, we could >> use a macro). But what would you think of a SIGILL handler which does >> not longjmp (like Jan suggested, simply print an error message and exit, >> even if xeno_bind_skin_opt was called) ? >> > > Fine with me. Ok. Commited in trunk. Do I commit in v2.4.x branch? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Gilles Chanteperdrix wrote: > Philippe Gerum wrote: >> Gilles Chanteperdrix wrote: >>> Hi, >>> >>> on some (all ?) platforms, we get a SIGILL when trying to emit the first >>> Xenomai syscall, instead of the -ENOSYS return value. This patches >>> handles the SIGILL by printing an error message and exiting. >>> >> This is an issue for archs that encode the syscall number into the trap >> opcode >> like ARM using the OABI, others will get -ENOSYS as expected, so this should >> move to the arch-specific code. > > Actually, I get a SIGILL on ARM compiled with EABI as well. It seems the ARM folks decided to send SIGILL with EABI to conform to the OABI behaviour, despite they did not formally need that. Only invalid calls in the 9f00xx..9f07ff range are expected to return -ENOSYS. Too bad that our syscall marker is out of that range. Moving this > code to the arch dependent code looks hard, since we need to setup the > jump buffer in the very function which issues the syscall (Ok, we could > use a macro). But what would you think of a SIGILL handler which does > not longjmp (like Jan suggested, simply print an error message and exit, > even if xeno_bind_skin_opt was called) ? > Fine with me. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>> Gilles Chanteperdrix wrote:
>>> Hi,
>>>
>>> on some (all ?) platforms, we get a SIGILL when trying to emit the first
>>> Xenomai syscall, instead of the -ENOSYS return value. This patches
>>> handles the SIGILL by printing an error message and exiting.
>>>
>> This is an issue for archs that encode the syscall number into the trap
>> opcode
>> like ARM using the OABI, others will get -ENOSYS as expected, so this should
>> move to the arch-specific code.
>
> Actually, I get a SIGILL on ARM compiled with EABI as well. Moving this
> code to the arch dependent code looks hard, since we need to setup the
> jump buffer in the very function which issues the syscall (Ok, we could
> use a macro). But what would you think of a SIGILL handler which does
> not longjmp (like Jan suggested, simply print an error message and exit,
> even if xeno_bind_skin_opt was called) ?
>
So, here is another version.
Index: include/asm-generic/bits/bind.h
===
--- include/asm-generic/bits/bind.h (revision 4175)
+++ include/asm-generic/bits/bind.h (working copy)
@@ -99,15 +99,32 @@ static void unmap_sem_heap(unsigned long
}
#endif /* CONFIG_XENO_FASTSEM */
+void __attribute__((weak)) xeno_sigill_handler(int sig)
+{
+ fprintf(stderr, "Xenomai or CONFIG_XENO_OPT_PERVASIVE disabled.\n"
+ "(modprobe xeno_nucleus?)\n");
+ exit(1);
+}
+
static inline int
xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)
{
+ sighandler_t old_sigill_handler;
struct sigaction sa;
xnfeatinfo_t finfo;
int muxid;
+ old_sigill_handler = signal(SIGILL, xeno_sigill_handler);
+ if (old_sigill_handler == SIG_ERR) {
+ perror("signal(SIGILL)");
+ exit(1);
+ }
+
muxid = XENOMAI_SYSBIND(skin_magic,
XENOMAI_FEAT_DEP, XENOMAI_ABI_REV, &finfo);
+
+ signal(SIGILL, old_sigill_handler);
+
switch (muxid) {
case -EINVAL:
@@ -180,11 +197,21 @@ xeno_bind_skin(unsigned skin_magic, cons
static inline int
xeno_bind_skin_opt(unsigned skin_magic, const char *skin, const char *module)
{
+ sighandler_t old_sigill_handler;
xnfeatinfo_t finfo;
int muxid;
+ old_sigill_handler = signal(SIGILL, xeno_sigill_handler);
+ if (old_sigill_handler == SIG_ERR) {
+ perror("signal(SIGILL)");
+ exit(1);
+ }
+
muxid = XENOMAI_SYSBIND(skin_magic,
XENOMAI_FEAT_DEP, XENOMAI_ABI_REV, &finfo);
+
+ signal(SIGILL, old_sigill_handler);
+
switch (muxid) {
case -EINVAL:
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Philippe Gerum wrote: > Gilles Chanteperdrix wrote: >> Hi, >> >> on some (all ?) platforms, we get a SIGILL when trying to emit the first >> Xenomai syscall, instead of the -ENOSYS return value. This patches >> handles the SIGILL by printing an error message and exiting. >> > > This is an issue for archs that encode the syscall number into the trap opcode > like ARM using the OABI, others will get -ENOSYS as expected, so this should > move to the arch-specific code. Actually, I get a SIGILL on ARM compiled with EABI as well. Moving this code to the arch dependent code looks hard, since we need to setup the jump buffer in the very function which issues the syscall (Ok, we could use a macro). But what would you think of a SIGILL handler which does not longjmp (like Jan suggested, simply print an error message and exit, even if xeno_bind_skin_opt was called) ? -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Gilles Chanteperdrix wrote:
> Hi,
>
> on some (all ?) platforms, we get a SIGILL when trying to emit the first
> Xenomai syscall, instead of the -ENOSYS return value. This patches
> handles the SIGILL by printing an error message and exiting.
>
This is an issue for archs that encode the syscall number into the trap opcode
like ARM using the OABI, others will get -ENOSYS as expected, so this should
move to the arch-specific code.
> Index: include/asm-generic/bits/bind.h
> ===
> --- include/asm-generic/bits/bind.h (revision 4175)
> +++ include/asm-generic/bits/bind.h (working copy)
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
Oh dear... Yeah, this should really be buried into the ARM support code.
> #include
> #include
> #include
> @@ -17,6 +18,8 @@ __attribute__ ((weak))
> pthread_key_t xeno_current_key;
> __attribute__ ((weak))
> pthread_once_t xeno_init_current_key_once = PTHREAD_ONCE_INIT;
> +__attribute__ ((weak))
> +jmp_buf xeno_sigill_jmpbuf;
>
> __attribute__ ((weak))
> void xeno_set_current(void)
> @@ -99,13 +102,28 @@ static void unmap_sem_heap(unsigned long
> }
> #endif /* CONFIG_XENO_FASTSEM */
>
> +void __attribute__((weak)) xeno_sigill_handler(int sig)
> +{
> + siglongjmp(xeno_sigill_jmpbuf, 1);
> +}
> +
> static inline int
> xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)
> {
> + sighandler_t old_sigill_handler;
> struct sigaction sa;
> xnfeatinfo_t finfo;
> int muxid;
>
> + old_sigill_handler = signal(SIGILL, xeno_sigill_handler);
> + if (old_sigill_handler == SIG_ERR) {
> + perror("signal(SIGILL)");
> + exit(1);
> + }
> +
> + if (sigsetjmp(xeno_sigill_jmpbuf, 1))
> + goto enosys;
> +
> muxid = XENOMAI_SYSBIND(skin_magic,
> XENOMAI_FEAT_DEP, XENOMAI_ABI_REV, &finfo);
> switch (muxid) {
> @@ -126,7 +144,7 @@ xeno_bind_skin(unsigned skin_magic, cons
>
> case -ENOSYS:
> case -ESRCH:
> -
> + enosys:
> fprintf(stderr,
> "Xenomai: %s skin or CONFIG_XENO_OPT_PERVASIVE
> disabled.\n"
> "(modprobe %s?)\n", skin, module);
> @@ -139,6 +157,8 @@ xeno_bind_skin(unsigned skin_magic, cons
> exit(1);
> }
>
> + signal(SIGILL, old_sigill_handler);
> +
> #ifdef xeno_arch_features_check
> xeno_arch_features_check();
> #endif /* xeno_arch_features_check */
> @@ -180,9 +200,19 @@ xeno_bind_skin(unsigned skin_magic, cons
> static inline int
> xeno_bind_skin_opt(unsigned skin_magic, const char *skin, const char *module)
> {
> + sighandler_t old_sigill_handler;
> xnfeatinfo_t finfo;
> int muxid;
>
> + old_sigill_handler = signal(SIGILL, xeno_sigill_handler);
> + if (old_sigill_handler == SIG_ERR) {
> + perror("signal(SIGILL)");
> + exit(1);
> + }
> +
> + if (sigsetjmp(xeno_sigill_jmpbuf, 1))
> + goto enosys;
> +
> muxid = XENOMAI_SYSBIND(skin_magic,
> XENOMAI_FEAT_DEP, XENOMAI_ABI_REV, &finfo);
> switch (muxid) {
> @@ -203,7 +233,7 @@ xeno_bind_skin_opt(unsigned skin_magic,
>
> case -ENOSYS:
> case -ESRCH:
> -
> + enosys:
> return -1;
> }
>
> @@ -213,6 +243,8 @@ xeno_bind_skin_opt(unsigned skin_magic,
> exit(1);
> }
>
> + signal(SIGILL, old_sigill_handler);
> +
> #ifdef xeno_arch_features_check
> xeno_arch_features_check();
> #endif /* xeno_arch_features_check */
>
>
>
--
Philippe.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
Hi,
on some (all ?) platforms, we get a SIGILL when trying to emit the first
>>> I don't see this on x86, though.
>>>
Xenomai syscall, instead of the -ENOSYS return value. This patches
handles the SIGILL by printing an error message and exiting.
Index: include/asm-generic/bits/bind.h
===
--- include/asm-generic/bits/bind.h(revision 4175)
+++ include/asm-generic/bits/bind.h(working copy)
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -17,6 +18,8 @@ __attribute__ ((weak))
pthread_key_t xeno_current_key;
__attribute__ ((weak))
pthread_once_t xeno_init_current_key_once = PTHREAD_ONCE_INIT;
+__attribute__ ((weak))
+jmp_buf xeno_sigill_jmpbuf;
__attribute__ ((weak))
void xeno_set_current(void)
@@ -99,13 +102,28 @@ static void unmap_sem_heap(unsigned long
}
#endif /* CONFIG_XENO_FASTSEM */
+void __attribute__((weak)) xeno_sigill_handler(int sig)
+{
+ siglongjmp(xeno_sigill_jmpbuf, 1);
+}
+
>>> Just one question: Can we safely assume that sigsetjmp&siglongjump are
>>> always available, also in uclibc environments e.g.?
>> Ok. We can use setjmp/longjmp and assume that only SIGILL is masked at
>> the longjmp call site ?
>
> Hmm, good question. But maybe this is a non-issue and sig{set|long}jmp
> is actually always available (these days). On first glance, ucLibc seems
> to have an implementation.
We can also manually save and restore the signal mask.
>
> Alternative idea: What about defining a common xenomai_does_not_exist
> service that warns and terminates? It could be called it both on ENOSYS
> and from the signal handler.
Yes, but in the xeno_bind_skin_opt case, we are expected to return a
status, and not exit. So, longjmp is the only way... Unless we accept to
exit in the SIGILL case.
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Hi,
>>>
>>> on some (all ?) platforms, we get a SIGILL when trying to emit the first
>> I don't see this on x86, though.
>>
>>> Xenomai syscall, instead of the -ENOSYS return value. This patches
>>> handles the SIGILL by printing an error message and exiting.
>>>
>>> Index: include/asm-generic/bits/bind.h
>>> ===
>>> --- include/asm-generic/bits/bind.h (revision 4175)
>>> +++ include/asm-generic/bits/bind.h (working copy)
>>> @@ -9,6 +9,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -17,6 +18,8 @@ __attribute__ ((weak))
>>> pthread_key_t xeno_current_key;
>>> __attribute__ ((weak))
>>> pthread_once_t xeno_init_current_key_once = PTHREAD_ONCE_INIT;
>>> +__attribute__ ((weak))
>>> +jmp_buf xeno_sigill_jmpbuf;
>>>
>>> __attribute__ ((weak))
>>> void xeno_set_current(void)
>>> @@ -99,13 +102,28 @@ static void unmap_sem_heap(unsigned long
>>> }
>>> #endif /* CONFIG_XENO_FASTSEM */
>>>
>>> +void __attribute__((weak)) xeno_sigill_handler(int sig)
>>> +{
>>> + siglongjmp(xeno_sigill_jmpbuf, 1);
>>> +}
>>> +
>> Just one question: Can we safely assume that sigsetjmp&siglongjump are
>> always available, also in uclibc environments e.g.?
>
> Ok. We can use setjmp/longjmp and assume that only SIGILL is masked at
> the longjmp call site ?
Hmm, good question. But maybe this is a non-issue and sig{set|long}jmp
is actually always available (these days). On first glance, ucLibc seems
to have an implementation.
Alternative idea: What about defining a common xenomai_does_not_exist
service that warns and terminates? It could be called it both on ENOSYS
and from the signal handler.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Hi,
>>
>> on some (all ?) platforms, we get a SIGILL when trying to emit the first
>
> I don't see this on x86, though.
>
>> Xenomai syscall, instead of the -ENOSYS return value. This patches
>> handles the SIGILL by printing an error message and exiting.
>>
>> Index: include/asm-generic/bits/bind.h
>> ===
>> --- include/asm-generic/bits/bind.h (revision 4175)
>> +++ include/asm-generic/bits/bind.h (working copy)
>> @@ -9,6 +9,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -17,6 +18,8 @@ __attribute__ ((weak))
>> pthread_key_t xeno_current_key;
>> __attribute__ ((weak))
>> pthread_once_t xeno_init_current_key_once = PTHREAD_ONCE_INIT;
>> +__attribute__ ((weak))
>> +jmp_buf xeno_sigill_jmpbuf;
>>
>> __attribute__ ((weak))
>> void xeno_set_current(void)
>> @@ -99,13 +102,28 @@ static void unmap_sem_heap(unsigned long
>> }
>> #endif /* CONFIG_XENO_FASTSEM */
>>
>> +void __attribute__((weak)) xeno_sigill_handler(int sig)
>> +{
>> +siglongjmp(xeno_sigill_jmpbuf, 1);
>> +}
>> +
>
> Just one question: Can we safely assume that sigsetjmp&siglongjump are
> always available, also in uclibc environments e.g.?
Ok. We can use setjmp/longjmp and assume that only SIGILL is masked at
the longjmp call site ?
--
Gilles.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Handle SIGILL when kernel compiled without Xenomai.
Gilles Chanteperdrix wrote:
> Hi,
>
> on some (all ?) platforms, we get a SIGILL when trying to emit the first
I don't see this on x86, though.
> Xenomai syscall, instead of the -ENOSYS return value. This patches
> handles the SIGILL by printing an error message and exiting.
>
> Index: include/asm-generic/bits/bind.h
> ===
> --- include/asm-generic/bits/bind.h (revision 4175)
> +++ include/asm-generic/bits/bind.h (working copy)
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -17,6 +18,8 @@ __attribute__ ((weak))
> pthread_key_t xeno_current_key;
> __attribute__ ((weak))
> pthread_once_t xeno_init_current_key_once = PTHREAD_ONCE_INIT;
> +__attribute__ ((weak))
> +jmp_buf xeno_sigill_jmpbuf;
>
> __attribute__ ((weak))
> void xeno_set_current(void)
> @@ -99,13 +102,28 @@ static void unmap_sem_heap(unsigned long
> }
> #endif /* CONFIG_XENO_FASTSEM */
>
> +void __attribute__((weak)) xeno_sigill_handler(int sig)
> +{
> + siglongjmp(xeno_sigill_jmpbuf, 1);
> +}
> +
Just one question: Can we safely assume that sigsetjmp&siglongjump are
always available, also in uclibc environments e.g.?
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
