linux-kernel - Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted

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: <20150122151657.287fe29b@gandalf.local.home>
Date:	Thu, 22 Jan 2015 15:16:57 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	Andrew Cooper <andrew.cooper3@...rix.com>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	david.vrabel@...rix.com, konrad.wilk@...cle.com,
	boris.ostrovsky@...cle.com, xen-devel@...ts.xenproject.org,
	kvm@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org,
	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...hat.com>,
	Jan Beulich <JBeulich@...e.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...e.de>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to
 be preempted


[ Added Paul McKenney ]

On Thu, 22 Jan 2015 19:39:13 +0100
"Luis R. Rodriguez" <mcgrof@...e.com> wrote:

> > Why not make this a tracepoint? Then you can enable it only when you
> > want to. As tracepoints are also hooks, you could add you own code that
> > hooks to it and does a printk as well. The advantage of doing it via a
> > tracepoint is that you can turn it on and off regardless of what the
> > loglevel is set at.
> 
> This uses NOKPROBE_SYMBOL and notrace since based on Andy's advice
> we are not confident that tracing and kprobes are safe to use in what
> might be an extended RCU quiescent state (i.e. where we're outside
> irq_enter and irq_exit).

We have trace_*_rcuidle() for such cases.

That is, you create the tracepoint just the same, and instead of having
trace_foo(), if you are in a known area that is outside of rcu viewing,
you use trace_foo_rcuidle() and it will tell RCU "hey, there's something
here that may need RCU, so look at me!"

Also, please remove the "notrace", because function tracing goes an
extra step to not require RCU being visible. The only thing you get
with notrace is not being able to trace an otherwise traceable function.

-- Steve

> 
> > That is, if there is any practical use for that message. Tracing just
> > sched_switch will give you the same info.
> 
> IMHO it may be more useful if we knew exactly what hypercalls were
> being preempted but perhaps all that can be left as a secondary
> exercise and for now I'll just nuke the print.
--
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/