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: <20200625233552.2c8a0d1e@oasis.local.home>
Date:   Thu, 25 Jun 2020 23:35:52 -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 22:36:11 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> +static void rb_time_set(rb_time_t *t, u64 val)
> +{
> +	struct rb_time_read r;
> +
> +	rb_time_read_set(&r, val);
> +
> +	do {
> +		r.start_cnt = local_inc_return(&t->start_cnt);
> +		local_set(&t->top, r.top);
> +		local_set(&t->bottom, r.bottom);
> +		local_set(&t->end_cnt, r.start_cnt);
> +	} while (r.start_cnt != local_read(&t->start_cnt));
> +}
> +
> +static bool rb_time_read_cmpxchg(local_t *l, unsigned long expect, unsigned long set)
> +{
> +	unsigned long ret;
> +
> +	ret = local_cmpxchg(l, expect, set);
> +	return ret == expect;
> +}
> +
> +static bool rb_time_cmpxchg(rb_time_t *t, u64 expect, u64 set)
> +{
> +	struct rb_time_read e, s;
> +
> +	rb_time_read_set(&e, expect);
> +	rb_time_read_set(&s, set);
> +
> +	e.start_cnt = local_read(&t->start_cnt);
> +	e.end_cnt = local_read(&t->end_cnt);
> +
> +	s.start_cnt = e.start_cnt + 1;
> +	s.end_cnt = e.start_cnt;
> +
> +	if (!rb_time_read_cmpxchg(&t->start_cnt, e.start_cnt, s.start_cnt))
> +		return false;
> +	if (!rb_time_read_cmpxchg(&t->top, e.top, s.top))
> +		return false;
> +	if (!rb_time_read_cmpxchg(&t->bottom, e.bottom, s.bottom))
> +		return false;
> +	return rb_time_read_cmpxchg(&t->end_cnt, e.end_cnt, s.end_cnt);
> +}
> +

I have to think about this more, as I think there's a flaw in this
cmpxchg algorithm.

-- Steve