[Xenomai] [PATCH] Do not overwrite pre-existing SIGDEBUG handler in xeno_skin_bind

[Xenomai] [PATCH] Do not overwrite pre-existing SIGDEBUG handler in xeno_skin_bind

[Jan Kiszka]

In case the application already set a SIGDEBUG handler, let that one
handle any potential SIGDEBUG_NOMLOCK events and keep our handler
(xeno_handle_mlock_alert) out of the loop. This helps in scenarios where
skin libraries are loaded belatedly via dlopen.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

Anything that speaks against this? We ran into that issue with a large
application, and that can be one way to solve but should even make
sense in general.

 include/asm-generic/bits/bind.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/include/asm-generic/bits/bind.h b/include/asm-generic/bits/bind.h
index 269be95..f39c853 100644
--- a/include/asm-generic/bits/bind.h
+++ b/include/asm-generic/bits/bind.h
@@ -23,6 +23,11 @@ xeno_bind_skin(unsigned skin_magic, const char *skin, const char *module)
 		exit(EXIT_FAILURE);
 	}
 
+	/* do not overwrite an already installed SIGDEBUG handler */
+	sigaction(SIGXCPU, NULL, &sa);
+	if (sa.sa_handler != SIG_DFL)
+		return muxid;
+
 	sa.sa_sigaction = xeno_handle_mlock_alert;
 	sigemptyset(&sa.sa_mask);
 	sa.sa_flags = SA_SIGINFO;
-- 
1.7.3.4

Re: [Xenomai] [PATCH] Do not overwrite pre-existing SIGDEBUG handler in xeno_skin_bind

[Gilles Chanteperdrix]

On 03/13/2013 03:53 PM, Jan Kiszka wrote:

> In case the application already set a SIGDEBUG handler, let that one
> handle any potential SIGDEBUG_NOMLOCK events and keep our handler
> (xeno_handle_mlock_alert) out of the loop. This helps in scenarios where
> skin libraries are loaded belatedly via dlopen.


Another option would be to save the previous handler, and call it when
we detect the signal is not due to an mlock alert.

-- 
                                                                Gilles.

Re: [Xenomai] [PATCH] Do not overwrite pre-existing SIGDEBUG handler in xeno_skin_bind

[Jan Kiszka]

On 2013-03-13 21:53, Gilles Chanteperdrix wrote:
> On 03/13/2013 03:53 PM, Jan Kiszka wrote:
> 
>> In case the application already set a SIGDEBUG handler, let that one
>> handle any potential SIGDEBUG_NOMLOCK events and keep our handler
>> (xeno_handle_mlock_alert) out of the loop. This helps in scenarios where
>> skin libraries are loaded belatedly via dlopen.
> 
> 
> Another option would be to save the previous handler, and call it when
> we detect the signal is not due to an mlock alert.

I've no preference. Pushed that variant now into my queue.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux