[PATCH v2] ftrace: ftrace_preempt_disable comment fix

From: Steven Rostedt
Date: Tue Nov 04 2008 - 16:54:38 EST



[
Changes since v1:

Fixed "need_recshed" to "need_resched"
]

Impact: comment fixes

Updates to ftrace_preempt_disable comments as recommended
by Andrew Morton.

Signed-off-by: Steven Rostedt <srostedt@xxxxxxxxxx>
---
kernel/trace/trace.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

Index: linux-trace.git/kernel/trace/trace.h
===================================================================
--- linux-trace.git.orig/kernel/trace/trace.h 2008-11-04 16:48:25.000000000 -0500
+++ linux-trace.git/kernel/trace/trace.h 2008-11-04 16:50:30.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.
+ * To prevent this, we read the need_resched flag before
+ * 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/