Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3238356yba; Mon, 6 May 2019 20:23:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqy/I0tTUV5R2rjO9PinNs2IfvcCq7sJm/fsV1YcdlRDCZG39EUhUvlmI1cNc3Zfo4tnq19/ X-Received: by 2002:a17:902:7c8f:: with SMTP id y15mr18476101pll.339.1557199395279; Mon, 06 May 2019 20:23:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557199395; cv=none; d=google.com; s=arc-20160816; b=gHNss+gE4nn+T2jXgFXkZP9R8ieP5Z1ZAccVGYmL2B4G3SxkvVXks1yZlDAD1WCQgS JQc2EFgkwL3y2O0YA7QqHvNZILjLF/NrvjLOhzEPOgsGuLnnNIidgh4w+sPYbZf5cs1O j3yHEn7106nI2F8df9dWHwR22ig287jP3+5uyThS/MMaGkf8aw3/X9lgytlt/NTqav+8 T27zmQczjBoUuENt/LQPmVxF2oVf+PmiimHRy8/2gr1oSYAewATIKt2UjNMjO8afttm8 m26JDKVCPrlIsC/GTcBq8FUGjcQCsprTpdNuSdW99YzOiurrEqdTookUUHeqYwSRIVcT sBnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=8Ij/IpNTUDCwuy3u8bG3fUXQYF8Lrau5dZVHZydVkNY=; b=L8eoEF+bxKhUcE35UqNiXpUM/H9Ng1nQp1o3faHaJXfK3sYDMJ5XurzhMFW9BDOZiu sV6SShpwsPNVQGp81f6uBd/aVlNBCAN0aJa63YH70YS8M2GkVyBVeBvI7yjwPofPD/rg 6MTtAIEIXgJt1v4WEZXfniIYE4p24Q2GknBLJ0huAkCv1LEJoJ3UjaPkCg2NoSWrw9UX jY/04rtuqFzUh1+P8tmKS2RZlvcH15rNR5chxepHQOkzVVU4jrQ9X9Z+w2v8M4CgZoc8 pgbUo3d9UeZIFiH+7ZO5W/mwx6gjV7kW6ohmMh8dXV9FlL1T7xRfrgzZWr9uOeHdxGqa FSeA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cm10si16316813plb.124.2019.05.06.20.22.57; Mon, 06 May 2019 20:23:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726888AbfEGDWD (ORCPT + 99 others); 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