[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150123191649.GZ17887@wotan.suse.de>
Date: Fri, 23 Jan 2015 20:16:49 +0100
From: "Luis R. Rodriguez" <mcgrof@...e.com>
To: David Vrabel <david.vrabel@...rix.com>,
Andy Lutomirski <luto@...capital.net>,
Steven Rostedt <rostedt@...dmis.org>
Cc: "Luis R. Rodriguez" <mcgrof@...not-panic.com>,
konrad.wilk@...cle.com, boris.ostrovsky@...cle.com,
xen-devel@...ts.xenproject.org, Borislav Petkov <bp@...e.de>,
kvm@...r.kernel.org, x86@...nel.org, linux-kernel@...r.kernel.org,
rostedt@...dmis.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>,
paulmck@...ux.vnet.ibm.com
Subject: Re: [Xen-devel] [RFC v4 2/2] x86/xen: allow privcmd hypercalls to
be preempted
On Fri, Jan 23, 2015 at 11:45:06AM +0000, David Vrabel wrote:
> > + */
> > +void xen_end_upcall(struct pt_regs *regs)
> > +{
> > + if (xen_is_preemptible_hypercall(regs)) {
> > + int cpuid = smp_processor_id();
> > + if (_cond_resched())
> > + trace_xen_hypercall_preemption(cpuid);
>
> I don't think a tracepoint here is useful.
OK.. I'll remove.
> > + }
> > +}
> > +NOKPROBE_SYMBOL(xen_end_upcall);
>
> Do we need this is this function is no longer notrace?
Stephen and Andy were going down some corner case rabbit hole
and it seemed to me that the conclusion was not settled so
to be safe I kept it. I'll let them decide. I did remove
the notrace junk.
Luis
--
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/
Powered by blists - more mailing lists