From: Greg KH on
2.6.27-stable review patch. If anyone has any objections, please let us know.


From: Wang Sheng-Hui <crosslonelyover(a)>

[No matching upstream git commit id as it was fixed differently due to a
rewrite of the tracing code there.]

For normal case, the code in trace_free_page() do once more substraction
on tracing_pages_allocated, but for CONFIG_TRACER_MAX_TRACE  it doesn't
take the freed page into account. That's not consistent with
trace_alloc_page(). Well, for there are no message related with this,
so we cannot observe its incorrect state when the kernel doesn't define
"CONFIG_TRACER_MAX_TRACE". If you add some pr_info() as
trace_alloc_page(), you may notice it.

Cc: Steven Rostedt <rostedt(a)>
Cc: Frederic Weisbecker <fweisbec(a)>
Cc: Ingo Molnar <mingo(a)>
Cc: Li Zefan <lizf(a)>
Signed-off-by: Wang Sheng-Hui <crosslonelyover(a)>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)>

kernel/trace/trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -3018,7 +3018,6 @@ static int trace_free_page(void)
- tracing_pages_allocated--;

@@ -3036,6 +3035,7 @@ static int trace_free_page(void)
page = list_entry(p, struct page, lru);
+ tracing_pages_allocated--;


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)
More majordomo info at
Please read the FAQ at