From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5093AC04AAD for ; Tue, 7 May 2019 03:22:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2BF4520989 for ; Tue, 7 May 2019 03:22:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726915AbfEGDWD (ORCPT ); Mon, 6 May 2019 23:22:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:54858 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726512AbfEGDWD (ORCPT ); Mon, 6 May 2019 23:22:03 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A1B47206BF; Tue, 7 May 2019 03:21:59 +0000 (UTC) Date: Mon, 6 May 2019 23:21:58 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Peter Zijlstra , Andy Lutomirski , Linux List Kernel Mailing , Ingo Molnar , Andrew Morton , Andy Lutomirski , Nicolai Stange , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "the arch/x86 maintainers" , Josh Poimboeuf , Jiri Kosina , Miroslav Benes , Petr Mladek , Joe Lawrence , Shuah Khan , Konrad Rzeszutek Wilk , Tim Chen , Sebastian Andrzej Siewior , Mimi Zohar , Juergen Gross , Nick Desaulniers , Nayna Jain , Masahiro Yamada , Joerg Roedel , "open list:KERNEL SELFTEST FRAMEWORK" , stable , Masami Hiramatsu Subject: Re: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions Message-ID: <20190506232158.13c9123b@oasis.local.home> In-Reply-To: References: <20190502181811.GY2623@hirez.programming.kicks-ass.net> <20190506095631.6f71ad7c@gandalf.local.home> <20190506130643.62c35eeb@gandalf.local.home> <20190506145745.17c59596@gandalf.local.home> <20190506162915.380993f9@gandalf.local.home> <20190506174511.2f8b696b@gandalf.local.home> <20190506210416.2489a659@oasis.local.home> <20190506215353.14a8ef78@oasis.local.home> <20190506225819.11756974@oasis.local.home> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 6 May 2019 20:05:24 -0700 Linus Torvalds wrote: > It would emulate the call that has had its first byte overwritten by > 'int3'. Without doing any lookups of what it was supposed to change > the call to, because it simply depends on what the rewriting code is > doing on another CPU (or on the same CPU - it wouldn't care). OK, so this is just about what to have it call. > > So no need to look up anything, not at int3 time, and not at return > time. It would just emulate the instruction atomically, with no state, > and no need to look up what the 'ip' instruction is at the time. > > It could literally just use a single flag: "is ftrace updating call > instructions". Add another flag for the "I'm nop'ing out call > instructions" so that it knows to emulate a jump-over instead. That's > it. Well we have that, and we have to look up the record regardless to know if this was a ftrace int3 or not (the ftrace_location(ip) does that). And the record has a counter to # of attached callers. Zero being to turn it into a nop. Note, if we are going from nop to call or call to nop, it would need to read the offset to see if it is a nop (don't want to call with the nop offset) > > Because all the actual *values* would be entirely be determined by the > actual rewriting that is going on independently of the 'int3' > exception. But still, we need to emulate the call, which requires pushing the return code back onto the stack. I believe that part is the part we are struggling with. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: rostedt at goodmis.org (Steven Rostedt) Date: Mon, 6 May 2019 23:21:58 -0400 Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions In-Reply-To: References: <20190502181811.GY2623@hirez.programming.kicks-ass.net> <20190506095631.6f71ad7c@gandalf.local.home> <20190506130643.62c35eeb@gandalf.local.home> <20190506145745.17c59596@gandalf.local.home> <20190506162915.380993f9@gandalf.local.home> <20190506174511.2f8b696b@gandalf.local.home> <20190506210416.2489a659@oasis.local.home> <20190506215353.14a8ef78@oasis.local.home> <20190506225819.11756974@oasis.local.home> Message-ID: <20190506232158.13c9123b@oasis.local.home> On Mon, 6 May 2019 20:05:24 -0700 Linus Torvalds wrote: > It would emulate the call that has had its first byte overwritten by > 'int3'. Without doing any lookups of what it was supposed to change > the call to, because it simply depends on what the rewriting code is > doing on another CPU (or on the same CPU - it wouldn't care). OK, so this is just about what to have it call. > > So no need to look up anything, not at int3 time, and not at return > time. It would just emulate the instruction atomically, with no state, > and no need to look up what the 'ip' instruction is at the time. > > It could literally just use a single flag: "is ftrace updating call > instructions". Add another flag for the "I'm nop'ing out call > instructions" so that it knows to emulate a jump-over instead. That's > it. Well we have that, and we have to look up the record regardless to know if this was a ftrace int3 or not (the ftrace_location(ip) does that). And the record has a counter to # of attached callers. Zero being to turn it into a nop. Note, if we are going from nop to call or call to nop, it would need to read the offset to see if it is a nop (don't want to call with the nop offset) > > Because all the actual *values* would be entirely be determined by the > actual rewriting that is going on independently of the 'int3' > exception. But still, we need to emulate the call, which requires pushing the return code back onto the stack. I believe that part is the part we are struggling with. -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: rostedt@goodmis.org (Steven Rostedt) Date: Mon, 6 May 2019 23:21:58 -0400 Subject: [RFC][PATCH 1/2] x86: Allow breakpoints to emulate call functions In-Reply-To: References: <20190502181811.GY2623@hirez.programming.kicks-ass.net> <20190506095631.6f71ad7c@gandalf.local.home> <20190506130643.62c35eeb@gandalf.local.home> <20190506145745.17c59596@gandalf.local.home> <20190506162915.380993f9@gandalf.local.home> <20190506174511.2f8b696b@gandalf.local.home> <20190506210416.2489a659@oasis.local.home> <20190506215353.14a8ef78@oasis.local.home> <20190506225819.11756974@oasis.local.home> Message-ID: <20190506232158.13c9123b@oasis.local.home> Content-Type: text/plain; charset="UTF-8" Message-ID: <20190507032158.WmCxevo6iwjPmMd_K5aMJvPGAYRZR0y8dKsDITLzz8U@z> On Mon, 6 May 2019 20:05:24 -0700 Linus Torvalds wrote: > It would emulate the call that has had its first byte overwritten by > 'int3'. Without doing any lookups of what it was supposed to change > the call to, because it simply depends on what the rewriting code is > doing on another CPU (or on the same CPU - it wouldn't care). OK, so this is just about what to have it call. > > So no need to look up anything, not at int3 time, and not at return > time. It would just emulate the instruction atomically, with no state, > and no need to look up what the 'ip' instruction is at the time. > > It could literally just use a single flag: "is ftrace updating call > instructions". Add another flag for the "I'm nop'ing out call > instructions" so that it knows to emulate a jump-over instead. That's > it. Well we have that, and we have to look up the record regardless to know if this was a ftrace int3 or not (the ftrace_location(ip) does that). And the record has a counter to # of attached callers. Zero being to turn it into a nop. Note, if we are going from nop to call or call to nop, it would need to read the offset to see if it is a nop (don't want to call with the nop offset) > > Because all the actual *values* would be entirely be determined by the > actual rewriting that is going on independently of the 'int3' > exception. But still, we need to emulate the call, which requires pushing the return code back onto the stack. I believe that part is the part we are struggling with. -- Steve