All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Xenomai-core@domain.hid
Subject: [Xenomai-core] [PATCH] Optional timer freeze during ptracing
Date: Fri, 08 Feb 2008 23:00:31 +0100	[thread overview]
Message-ID: <47ACD0FF.8000601@domain.hid> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 798 bytes --]

Freezing all Xenomai timers while just a single RT application is under
ptrace control can be helpful in certain debugging scenarios, but it can
as well be harmful when other parts of the systems have to continue to work.

I brought this concern up back in 2006, and I originally thought we may
address this by freezing per process. But this is far too complex for a
simple problem like this: Just make the whole thing configurable, and
keep it off by default so that -ideally- only users who are aware of the
side effects will arm it.

Gilles, you recently stumbled over such a side effect and introduced
XNTIMER_NOBLCK (for customized timer instrumentations as far as I
understood this). Do you think we still need that knob when we have
CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE?

Jan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: make-ptrace-timer-freeze-optional.patch --]
[-- Type: text/x-patch; name="make-ptrace-timer-freeze-optional.patch", Size: 3146 bytes --]

---
 ksrc/nucleus/Kconfig  |   14 ++++++++++++++
 ksrc/nucleus/shadow.c |   22 ++++++++--------------
 2 files changed, 22 insertions(+), 14 deletions(-)

Index: b/ksrc/nucleus/Kconfig
===================================================================
--- a/ksrc/nucleus/Kconfig
+++ b/ksrc/nucleus/Kconfig
@@ -194,6 +194,20 @@ config XENO_OPT_DEBUG_TIMERS
 	This option activates debugging output for critical
 	timer-related operations performed by the Xenomai core.
 
+config XENO_OPT_PTRACE_TIMER_FREEZE
+	bool "Freeze timers while debugging applications"
+	depends on XENO_OPT_DEBUG
+	help
+
+	If this feature is enabled, Xenomai no longer fires timers
+	while some real-time application is being debugged via
+	ptrace (gdb etc.). This can ease stepping through real-time
+	applications as it avoids certain types of timeouts to ocure
+	due to the debugging-related delays. On the other hand, this
+	global freeze can cause unwanted side-effects to other,
+	unrelated components in the system that rely on timers
+	continue to work.
+
 config XENO_OPT_WATCHDOG
 	bool "Watchdog support"
 	depends on XENO_OPT_DEBUG
Index: b/ksrc/nucleus/shadow.c
===================================================================
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -840,18 +840,6 @@ static inline void set_linux_task_priori
 		       prio, p->comm);
 }
 
-static inline void lock_timers(void)
-{
-	xnarch_atomic_inc(&nkpod->timerlck);
-	setbits(nktbase.status, XNTBLCK);
-}
-
-static inline void unlock_timers(void)
-{
-	if (xnarch_atomic_dec_and_test(&nkpod->timerlck))
-		clrbits(nktbase.status, XNTBLCK);
-}
-
 static void xnshadow_dereference_skin(unsigned magic)
 {
 	unsigned muxid;
@@ -2199,6 +2187,7 @@ static inline void do_schedule_event(str
 		   SIGSTOP and SIGINT in order to encompass both the NPTL and
 		   LinuxThreads behaviours. */
 
+#ifdef CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE
 		if (xnthread_test_info(threadin, XNDEBUG)) {
 			if (signal_pending(next)) {
 				sigset_t pending;
@@ -2213,10 +2202,12 @@ static inline void do_schedule_event(str
 			}
 
 			xnthread_clear_info(threadin, XNDEBUG);
-			unlock_timers();
+			if (xnarch_atomic_dec_and_test(&nkpod->timerlck))
+				clrbits(nktbase.status, XNTBLCK);
 		}
 
 	      no_ptrace:
+#endif /* CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE */
 
 		if (XENO_DEBUG(NUCLEUS)) {
 			int sigpending = signal_pending(next);
@@ -2261,6 +2252,7 @@ static inline void do_sigwake_event(stru
 
 	xnlock_get_irqsave(&nklock, s);
 
+#ifdef CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE
 	if ((p->ptrace & PT_PTRACED) && !xnthread_test_info(thread, XNDEBUG)) {
 		sigset_t pending;
 
@@ -2271,9 +2263,11 @@ static inline void do_sigwake_event(stru
 		    sigismember(&pending, SIGSTOP)
 		    || sigismember(&pending, SIGINT)) {
 			xnthread_set_info(thread, XNDEBUG);
-			lock_timers();
+			xnarch_atomic_inc(&nkpod->timerlck);
+			setbits(nktbase.status, XNTBLCK);
 		}
 	}
+#endif /* CONFIG_XENO_OPT_PTRACE_TIMER_FREEZE */
 
 	if (xnthread_test_state(thread, XNRELAX))
 		goto unlock_and_exit;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]

             reply	other threads:[~2008-02-08 22:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-08 22:00 Jan Kiszka [this message]
2008-02-09 13:31 ` [Xenomai-core] [PATCH] Optional timer freeze during ptracing Gilles Chanteperdrix
2008-02-09 15:19 ` Philippe Gerum
2008-02-09 16:06   ` Jan Kiszka
2008-02-09 16:33     ` 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=47ACD0FF.8000601@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=Xenomai-core@domain.hid \
    /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.