linux-kernel - Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer

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, 19 Aug 2016 10:26:20 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Clark Williams <williams@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jon Masters <jcm@...hat.com>, Daniel Wagner <wagi@...om.org>,
        Carsten Emde <C.Emde@...dl.org>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [PATCH v2 0/4] tracing: Add Hardware Latency detector tracer

On Fri, 19 Aug 2016 16:09:28 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> On Wed, Aug 10, 2016 at 09:53:56AM -0400, Steven Rostedt wrote:
> > Changes since v1:
> > 
> >  . Added checks for CONFIG_GENERIC_SCHED_CLOCK, and if that is set,
> >    only nmi_counts will be recorded when an NMI is triggered, but not
> >    the time in NMI, because the generic sched_clock is not NMI safe.
> >    (suggested by Sebastian Andrzej Siewior)  
> 
> So any of the platforms using GENERIC_SCHED_CLOCK _have_ NMIs ?

>From what I gather, the answer is no, so I don't think this is an issue.

> 
> In any case, for those you could probably use ktime_get_mono_fast_ns().

Is that safe to call from NMI? Looking into the code I see:

	now = ktime_to_ns(tkr->base) + timekeeping_get_ns(tkr);

where timekeeping_get_ns() has:

	timekeeping_get_delta()

which does:

	read_seqcount_begin()

which has (eventually):

repeat:
	ret = READ_ONCE(s->sequence);
	if (unlikely(ret & 1)) {
		cpu_relax();
		goto repeat;
	}
	return ret;

Which I think could cause a deadlock from an NMI.

-- Steve