From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752406AbdHHTNs (ORCPT ); Tue, 8 Aug 2017 15:13:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53654 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752030AbdHHTNq (ORCPT ); Tue, 8 Aug 2017 15:13:46 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7342B8BD22 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Tue, 8 Aug 2017 14:13:44 -0500 From: Josh Poimboeuf To: Linus Torvalds Cc: "Levin, Alexander (Sasha Levin)" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "live-patching@vger.kernel.org" , Andy Lutomirski , Jiri Slaby , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Mike Galbraith Subject: Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder Message-ID: <20170808191344.kw5nlicmq4g6fpii@treble> References: <0a6cbfb40f8da99b7a45a1a8302dc6aef16ec812.1500938583.git.jpoimboe@redhat.com> <20170728164844.tee7ujqluv2fgarf@sasha-lappy> <20170728175234.pmou7z6dosbi7krh@treble> <20170728182954.imivl45vrc7toarp@sasha-lappy> <20170728185720.fwczcezbkrlxmwqb@treble> <20170728195912.panyn4p6e6ovueey@sasha-lappy> <20170729035437.fmnxmeedrq55bpwm@treble> <20170808185809.qaug762cj7nw3bcd@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 08 Aug 2017 19:13:46 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 08, 2017 at 12:03:51PM -0700, Linus Torvalds wrote: > On Tue, Aug 8, 2017 at 11:58 AM, Josh Poimboeuf wrote: > > > > Take for example the lock_is_held_type() function. In vmlinux, it has > > the following instruction: > > > > callq *0xffffffff85a94880 (pv_irq_ops.save_fl) > > > > At runtime, that instruction is patched and replaced with a fast inline > > version of arch_local_save_flags() which eliminates the call: > > > > pushfq > > pop %rax > > > > The problem is when an interrupt hits after the push: > > > > pushfq > > --- irq --- > > pop %rax > > That should actually be something easily fixable, for an odd reason: > the instruction boundaries are different. > > > I'm not sure what the solution should be. It will probably need to be > > one of the following: > > > > a) either don't allow runtime "alternative" patches to mess with the > > stack pointer (objtool could enforce this); or > > > > b) come up with some way to register such patches with the ORC > > unwinder at runtime. > > c) just add ORC data for the alternative statically and _unconditionally_. > > No runtime registration. Just an unconditional entry for the > particular IP that comes after the "pushfq". It cannot match the > "callq" instruction, since it would be in the middle of that > instruction. > > Basically, just do a "union" of the ORC data for all the alternatives. > > Now, objtool should still verify that the instruction pointers for > alternatives are unique - or that they share the same ORC unwinder > information if they are not. > > But in cases like this, when the instruction boundaires are different, > things should "just work", with no need for any special cases. > > Hmm? Yeah, that might work. Objtool already knows about alternatives, so it might not be too hard. I'll try it. And it can spit out a warning if we get two different ORC states for the same address after doing the "union". Then I guess we'd have to rearrange things or sprinkle some nops to work around it. -- Josh