linux-kernel - [PATCH 0/1] ftrace/ring_buffer: reset reader page after consuming read

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]

Message-ID: <1398652660-4560-1-git-send-email-shan.hai@windriver.com>
Date:	Mon, 28 Apr 2014 10:37:39 +0800
From:	Shan Hai <shan.hai@...driver.com>
To:	<rostedt@...dmis.org>, <fweisbec@...il.com>, <mingo@...hat.com>
CC:	<linux-kernel@...r.kernel.org>
Subject: [PATCH 0/1] ftrace/ring_buffer: reset reader page after consuming read


Reading from the 'trace' file after force stopping (by signal) consuming
read reveals there are stale trace entries in the output, this patch fixes
the bug by resetting read/write pointers of reader page after the consuming
read is stopped by force.

The issue can be reproduced as below:

echo 0 > tracing_on
echo function > current_tracer
echo 1 > tracing_on

1, read the trace file as normal
        cat trace | head -n 20
        ...
        cat trace | head -n 20

        The trace entries are changing at the head of the output.
        NOTE:
        If it's not changing at the start please repeat the reading
        several times because the tracer need time to fill up the
        whole buffer.

2, read the trace file after stopping 'cat trace_pipe' by Ctrl-C
        cat trace_pipe
        Ctrl-C
        cat trace | head -n 200
        ...
        cat trace | head -n 200

        The trace entries at the head of the output stop changing,
        followed by changing trace entries.
        NOTE:
        Please carefully check the time stamps of the trace entries,
        the time stamps of some of them at the head stop changing
        in the consecutive read.

        The results of test 1 and 2 are not consistent with respect to the
        updating of trace buffers, some part of the trace buffers are
        not updated in the test 2 while all of them are updated in the
        test 1.

        And the result of test 1 is correct because the trace entries
        supposed to be changed for the reason the tracer works under
        overwrite mode by default.

Thanks
Shan Hai

--
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/