linux-kernel - Mmiotrace regression in 2.6.28-rc6

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 23 Nov 2008 15:41:48 +0200
From:	Pekka Paalanen <pq@....fi>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Pekka Paalanen <pq@....fi>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, fweisbec@...il.com
Subject: Mmiotrace regression in 2.6.28-rc6

Hi Steve,

now that the NULL deref bug in ring buffer resize is gone, I found
another regression.

It seems I am not getting any "buffer overflow" messages anymore.

Oh bummer, looks like I completely missed this one:
(hope it's not in any .27 kernel)

commit 3928a8a2d98081d1bc3c0a84a2d70e29b90ecf1c
Author: Steven Rostedt <rostedt@...dmis.org>
Date:   Mon Sep 29 23:02:41 2008 -0400

    ftrace: make work with new ring buffer

    This patch ports ftrace over to the new ring buffer.

    Signed-off-by: Steven Rostedt <srostedt@...hat.com>
    Signed-off-by: Ingo Molnar <mingo@...e.hu>

<...>
diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
index a108c32..bdbf09d 100644
--- a/kernel/trace/trace_mmiotrace.c
+++ b/kernel/trace/trace_mmiotrace.c
<...>
@@ -130,10 +130,14 @@ static unsigned long count_overruns(struct trace_iterator *iter)
 {
        int cpu;
        unsigned long cnt = 0;
+/* FIXME: */
+#if 0
        for_each_online_cpu(cpu) {
                cnt += iter->overrun[cpu];
                iter->overrun[cpu] = 0;
        }
+#endif
+       (void)cpu;
        return cnt;
 }

Steve, how am I going to fix this?
I think it's quite crucial to know when the dump is incomplete.

There's also another issue, but I am not sure how to reproduce it.
The symptom is, that
echo whatever > /debug/tracing/trace_marker
gets stuck in a loop, bash eats 100% CPU: 10% user, 90% system.
I got that twice today, like this: after a fresh boot echoing 64, 200,
70 to trace_entries, switching between nop and mmiotrace tracers,
echoing 0 or 1 to tracing_enabled, and running the testmmiotrace
module. At some point the user marker got stuck.

But then I tried to do that a third time by repeating some usage
patterns I thought might trigger it, but it didn't happen.

On the positive side, the basic test using testmmiotrace.ko
with the basic setup produces the correct output.

Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
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/