From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754721AbbAVVQ0 (ORCPT ); Thu, 22 Jan 2015 16:16:26 -0500 Received: from smtprelay0052.hostedemail.com ([216.40.44.52]:49831 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753039AbbAVVQW (ORCPT ); Thu, 22 Jan 2015 16:16:22 -0500 X-Session-Marker: 6E657665747340676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::::::::::::::::::::::::::::,RULES_HIT:41:355:379:541:599:800:960:968:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2198:2199:2393:2553:2559:2562:2693:2897:2904:3138:3139:3140:3141:3142:3354:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:5007:6120:6261:6742:7875:7903:8660:10004:10400:10848:10967:11232:11658:11914:12517:12519:12663:12740:13148:13230:14096:14097:21080,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0 X-HE-Tag: burst28_37259ae485161 X-Filterd-Recvd-Size: 4145 Date: Thu, 22 Jan 2015 16:16:17 -0500 From: Steven Rostedt To: Andy Lutomirski Cc: "Luis R. Rodriguez" , Andrew Cooper , "Luis R. Rodriguez" , David Vrabel , Konrad Rzeszutek Wilk , Boris Ostrovsky , "xen-devel@lists.xenproject.org" , kvm list , X86 ML , "linux-kernel@vger.kernel.org" , Ingo Molnar , Jan Beulich , "H. Peter Anvin" , Masami Hiramatsu , Thomas Gleixner , Borislav Petkov , "Paul E. McKenney" Subject: Re: [Xen-devel] [RFC v3 2/2] x86/xen: allow privcmd hypercalls to be preempted Message-ID: <20150122161617.0ee2b092@gandalf.local.home> In-Reply-To: References: <1421893039-426-1-git-send-email-mcgrof@do-not-panic.com> <1421893039-426-3-git-send-email-mcgrof@do-not-panic.com> <54C0E3F2.9050201@citrix.com> <20150122085649.7dc79541@grimm.local.home> <20150122183913.GO17887@wotan.suse.de> <20150122151657.287fe29b@gandalf.local.home> <20150122153707.4625878b@gandalf.local.home> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 22 Jan 2015 12:58:00 -0800 Andy Lutomirski wrote: > On Thu, Jan 22, 2015 at 12:37 PM, Steven Rostedt wrote: > > On Thu, 22 Jan 2015 12:24:47 -0800 > > Andy Lutomirski wrote: > > > >> > 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. > >> > > >> > >> Is this also true for kprobes? And can kprobes nest inside function > >> tracing hooks? > > > > No, kprobes are a bit more fragile than function tracing or tracepoints. > > > > And nothing should nest inside a function hook (except for interrupts, > > they are fine). > > > > But kprobes do nest inside interrupts, right? A kprobe being called while a function trace is happening is fine, but you should not have the kprobe set directly inside the function trace callback code. Because that means a kprobe could happen anywhere function tracing is happening (for instance, in NMI context). > > >> > >> The other issue, above and beyond RCU, is that we can't let kprobes > >> run on the int3 stack. If Xen upcalls can happen when interrupts are > >> off, then we may need this protection to prevent that type of > >> recursion. (This will be much less scary in 3.20, because userspace > >> int3 instructions will no longer execute on the int3 stack.) > > > > Does this execute between the start of the int3 interrupt handler and > > the call of do_int3()? > > I doubt it. > > The thing I worry about is that, if do_int3 nests inside itself by any > means (e.g. int3 sends a signal, scheduling for whatever reason > (really shouldn't happen, but I haven't looked that hard)), then we're > completely hosed -- the inner int3 will overwrite the outer int3's > stack frame. Since I have no idea what Xen upcalls do, I don't know > whether they can fire inside do_int3. I thought there's logic in the do_int3 handler (in the assembly code) that can handle nested int3s. I'm not sure what xen does though. -- Steve