All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: Jan Kiszka <jan.kiszka@domain.hid>, xenomai@xenomai.org
Subject: Re: [Xenomai-help] Handling Linux Signals in primary domain context
Date: Wed, 02 Jun 2010 11:15:36 +0200	[thread overview]
Message-ID: <1275470136.18250.16.camel@domain.hid> (raw)
In-Reply-To: <4C061823.70005@domain.hid>

On Wed, 2010-06-02 at 10:36 +0200, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
> > Tschaeche IT-Services wrote:
> >> On Tue, Jun 01, 2010 at 04:32:37PM +0200, Philippe Gerum wrote:
> >>> Not in the absence of syscall. We thought about this once already, when
> >>> considering how a watchdog preempting a runaway task in primary mode
> >>> could force a secondary mode switch: there is no sane and easy solution
> >>> to this unfortunately.
> >> This is exactly Sigmatek's problem: Our customers develop code
> >> within our debugging/development environment. We want to catch
> >> this situation (the developer implements a while(1)) with a
> >> watchdog throwing SIGTRAP so that our debugger gets active
> >> and can locate the problem according to the stack frame...
> > 
> > CONFIG_XENO_OPT_WATCHDOG is probably what you are looking for. It tries
> > to catch "well-behaving" broken threads via SIGDEBUG and kills the
> > hopelessly broken rest - system alive again.
> > 
> > You can then debug the former and need to do code review on the latter.
> > Or you could also try to add some loop-breaking Xenomai syscalls (or
> > even more clever checks) to library services the code under suspect
> > usually invokes.
> 
> I am afraid "well-behaving" means emitting syscalls. We have a radical
> way to cause a SIGSEGV to be sent to a thread having run amok: set its
> PC to an invalid address (after having printed the real PC). gdb will
> not be able to print where the program stopped, but should be able to
> print the backtrace.
> 

Actually, we could extend this logic and forge a stack frame to return
to the preempted application code via some userland trampoline code,
doing the switch:

[watchdog trigger]
	forge_return_frame(on =regs->sp, to =regs->pc);
	regs->pc = __oops_I_did_it_again;

__oops_I_did_it_again:
	__xn_migrate(LINUX_DOMAIN);
	ret (via forged frame)

The thing is, that this brings in some arch-dep code to forge a stack
frame (like the kernel uses for signals), that should rather live in the
pipeline core.


-- 
Philippe.




  parent reply	other threads:[~2010-06-02  9:15 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-01 13:50 [Xenomai-help] Handling Linux Signals in primary domain context Tschaeche IT-Services
2010-06-01 13:52 ` Gilles Chanteperdrix
2010-06-01 13:59 ` Gilles Chanteperdrix
2010-06-01 14:32 ` Philippe Gerum
2010-06-01 15:54   ` Tschaeche IT-Services
2010-06-01 16:52     ` Tschaeche IT-Services
2010-06-01 16:58     ` Jan Kiszka
2010-06-02  8:36       ` Gilles Chanteperdrix
2010-06-02  9:14         ` Jan Kiszka
2010-06-02  9:15         ` Philippe Gerum [this message]
2010-06-02  9:20           ` Jan Kiszka
2010-06-02  9:28             ` Philippe Gerum
2010-06-02  9:37               ` Gilles Chanteperdrix
2010-06-02 10:06                 ` Philippe Gerum
2010-06-02 10:19                   ` Gilles Chanteperdrix
2010-06-02 10:42                     ` Philippe Gerum
2010-06-02 10:51                       ` Gilles Chanteperdrix
2010-06-02 10:29                   ` Gilles Chanteperdrix
2010-06-02  9:21           ` Gilles Chanteperdrix
2010-06-02  9:23             ` Jan Kiszka
2010-06-02 10:19               ` Tschaeche IT-Services
2010-06-02 10:48                 ` Gilles Chanteperdrix
2010-06-02  9:34             ` Philippe Gerum
2010-06-02  9:43               ` Gilles Chanteperdrix
2010-06-02 12:02           ` Daniele Nicolodi
2010-06-02 13:47             ` Gilles Chanteperdrix
2010-06-02 15:14             ` Philippe Gerum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1275470136.18250.16.camel@domain.hid \
    --to=rpm@xenomai.org \
    --cc=gilles.chanteperdrix@xenomai.org \
    --cc=jan.kiszka@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.