Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754529AbbGXNWV (ORCPT ); Fri, 24 Jul 2015 09:22:21 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:9036 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753555AbbGXNWR (ORCPT ); Fri, 24 Jul 2015 09:22:17 -0400 Date: Fri, 24 Jul 2015 15:21:28 +0200 From: Willy Tarreau To: Steven Rostedt Cc: Peter Zijlstra , Linus Torvalds , Andy Lutomirski , X86 ML , "linux-kernel@vger.kernel.org" , Borislav Petkov , Thomas Gleixner , Brian Gerst Subject: Re: Dealing with the NMI mess Message-ID: <20150724132128.GA3612@1wt.eu> References: <20150723173105.6795c0dc@gandalf.local.home> <20150724081326.GO25159@twins.programming.kicks-ass.net> <20150724075841.40f209f4@gandalf.local.home> <20150724124304.GH19282@twins.programming.kicks-ass.net> <20150724090342.6d11e16d@gandalf.local.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150724090342.6d11e16d@gandalf.local.home> User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1470 Lines: 34 On Fri, Jul 24, 2015 at 09:03:42AM -0400, Steven Rostedt wrote: > On Fri, 24 Jul 2015 14:43:04 +0200 > Peter Zijlstra wrote: > > > > > I'm not too familiar with how to use hw breakpoints, but I'm guessing > > > (correct me if I'm wrong) that breakpoints on code that trigger when > > > executed, but watchpoints on data trigger when accessed. Then > > > copy_from_user_inatomic() would only trigger on watchpoints (it's not > > > executing that code, at least I hope it isn't!), and those wont bother > > > us. > > > > These things can be: RW, W, X. > > > > Sure, hitting a user X watchpoint is going to be 'interesting', but its > > fairly easy to hit a RW one. > > But do we care if we do hit one? The return from the #DB handler can > use a RET. Right? My understanding is that by using RET we can't set the RF flag and #DB will immediately strike again when the operation is attempted again. Thus we have to completely disable the breakpoints on leaving after the first one strikes, resulting in some userland breakpoints being missed. Maybe it can be accepted as a limitation when perf is running. I don't know if the output of perf is that relevant when a debugger is present BTW. Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/