linux-kernel - Re: [RFC][PATCH] ring-buffer: Have nested events still record running time stamp

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200625103753.4ac4a9a2@oasis.local.home>
Date:   Thu, 25 Jun 2020 10:37:53 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Yordan Karadzhov <y.karadz@...il.com>,
        Tzvetomir Stoyanov <tz.stoyanov@...il.com>,
        Tom Zanussi <zanussi@...nel.org>,
        Jason Behmer <jbehmer@...gle.com>,
        Julia Lawall <julia.lawall@...ia.fr>,
        Clark Williams <williams@...hat.com>,
        bristot <bristot@...hat.com>, Daniel Wagner <wagi@...om.org>,
        Darren Hart <dvhart@...are.com>,
        Jonathan Corbet <corbet@....net>,
        "Suresh E. Warrier" <warrier@...ux.vnet.ibm.com>
Subject: Re: [RFC][PATCH] ring-buffer: Have nested events still record
 running time stamp

On Thu, 25 Jun 2020 09:53:15 -0400 (EDT)
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> ----- On Jun 25, 2020, at 9:44 AM, rostedt rostedt@...dmis.org wrote:
> 
> > From: "Steven Rostedt (VMware)" <rostedt@...dmis.org>
> > 
> > [ SEVEN YEAR PROBLEM SOLVED! ]
> > 
> > Up until now, if an event is interrupted while it is recorded by an
> > interrupt, and that interrupt records events, the time of those events will
> > all be the same. This is because events only record the delta of the time
> > since the previous event (or beginning of a page), and to handle updating
> > the time keeping for that of nested events is extremely racy. After years of
> > thinking about this and several failed attempts, I finally have a solution
> > to solve this puzzle.  
> 
> Out of curiosity, considering that LTTng has solved this problem 10+ years ago
> with a simpler concurrency-friendly time-stamping model, why not simply use it
> rather than add complexity to the current ftrace timestamp scheme ?

Because it requires updating all the tools that read this from user
space.

I found a solution that works, so why change it and cause the backward
compatibility pain now?

-- Steve