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]

Date:   Fri, 26 Jun 2020 14:13:50 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     rostedt <rostedt@...dmis.org>
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 Jun 26, 2020, at 9:58 AM, rostedt rostedt@...dmis.org wrote:

> On Thu, 25 Jun 2020 23:35:52 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
>> I have to think about this more, as I think there's a flaw in this
>> cmpxchg algorithm.
> 
> Bah, that was all wrong. I need to incorporate the seq counter into the
> time stamp. Luckily I only use 59 bits for a full time stamp (gives me
> 18 years of nanoseconds), which gives me 5 bits to pay with, and all I
> need is 4 (2 for top and 2 for bottom). Now I can make the timestamp 60
> bits with 30 bits from the top and 30 from the bottom, and using two
> bits in each of those as a sequence counter.
> 
> If after reading top and bottom, if the seq bits match, then the two
> match and can be put together as a valid number. Now I have this:

[...]
> 
> static inline bool __rb_time_read(rb_time_t *t, u64 *ret, unsigned long *cnt)
> {
>	unsigned long top, bottom;
> 
>	top = local_read(&t->top);
>	bottom = local_read(&t->bottom);
> 
>	*cnt = rb_time_cnt(top);
> 
>	if (*cnt != rb_time_cnt(bottom))
>		return false;
> 
>	*ret = rb_time_val(top, bottom);
>	return true;
> }

If __rb_time_read or rb_time_cmpxchg are used in an interrupt over
rb_time_set (between setting top and bottom), those will never succeed.

How is this case handled ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com