makes sense - i've applied it to tip/tracing/urgent, see the tidied up
commit below.
It should be no big issue not being able to trace across suspend+resume
- and that restriction will go away with Steve's build-time based mcount
patching mechanism in v2.6.28.
Ingo
------------->
From 0e556695ddc8eebf6f6dd86bb0c4911b2b90c12a Mon Sep 17 00:00:00 2001
From: Rafael J. Wysocki <rjw@sisk.pl>
Date: Thu, 21 Aug 2008 21:59:36 +0200
Subject: [PATCH] ftrace: fix ftraced and suspend to ram
Steven Rostedt observed:
It will suffice to make it freezable, so that it doesn't run while the
system is suspending and resuming.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/trace/ftrace.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 639e16c..49f4c3f 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -819,8 +819,13 @@ static int ftraced(void *ignore)
{
unsigned long usecs;
+ set_freezable();
+
while (!kthread_should_stop()) {
+ if (try_to_freeze())
+ continue;
+
set_current_state(TASK_INTERRUPTIBLE);
/* check once a second */
--