[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0811041645330.15875@gandalf.stny.rr.com>
Date: Tue, 4 Nov 2008 16:48:10 -0500 (EST)
From: Steven Rostedt <rostedt@...dmis.org>
To: Ingo Molnar <mingo@...e.hu>
cc: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Steven Rostedt <srostedt@...hat.com>
Subject: [PATCH] ftrace: ftrace_preempt_disable comment fix
Impact: comment fixes
Updates to ftrace_preempt_disable comments as recommended to me
by Andrew Morton.
Signed-off-by: Steven Rostedt <srostedt@...hat.com>
---
kernel/trace/trace.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Index: linux-trace.git/kernel/trace/trace.h
===================================================================
--- linux-trace.git.orig/kernel/trace/trace.h 2008-11-04 16:32:57.000000000 -0500
+++ linux-trace.git/kernel/trace/trace.h 2008-11-04 16:36:11.000000000 -0500
@@ -425,17 +425,17 @@ extern struct tracer nop_trace;
* ftrace_preempt_disable - disable preemption scheduler safe
*
* When tracing can happen inside the scheduler, there exists
- * cases that the tracing might happen before the need_resched
+ * cases where tracing might happen before the need_resched
* flag is checked. If this happens and the tracer calls
* preempt_enable (after a disable), a schedule might take place
* causing an infinite recursion.
*
* To prevent this, we read the need_recshed flag before
- * disabling preemption. When we want to enable preemption we
- * check the flag, if it is set, then we call preempt_enable_no_resched.
- * Otherwise, we call preempt_enable.
+ * disabling preemption and store it. When we want to enable preemption
+ * we check the stored flag, if it is set, then we call
+ * preempt_enable_no_resched. Otherwise, we call preempt_enable.
*
- * The rational for doing the above is that if need resched is set
+ * The rationale for doing the above is that if need resched is set
* and we have yet to reschedule, we are either in an atomic location
* (where we do not need to check for scheduling) or we are inside
* the scheduler and do not want to resched.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists