From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752425AbdHHWA5 (ORCPT ); Tue, 8 Aug 2017 18:00:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44472 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752283AbdHHWAx (ORCPT ); Tue, 8 Aug 2017 18:00:53 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9A7247F3E2 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Tue, 8 Aug 2017 17:00:50 -0500 From: Josh Poimboeuf To: Andy Lutomirski Cc: Linus Torvalds , "Levin, Alexander (Sasha Levin)" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "live-patching@vger.kernel.org" , Jiri Slaby , Ingo Molnar , "H. Peter Anvin" , Peter Zijlstra , Mike Galbraith , Borislav Petkov Subject: Re: [PATCH v4 1/2] x86/unwind: add ORC unwinder Message-ID: <20170808220050.63yycmfyw6t2ydtt@treble> References: <20170728164844.tee7ujqluv2fgarf@sasha-lappy> <20170728175234.pmou7z6dosbi7krh@treble> <20170728182954.imivl45vrc7toarp@sasha-lappy> <20170728185720.fwczcezbkrlxmwqb@treble> <20170728195912.panyn4p6e6ovueey@sasha-lappy> <20170729035437.fmnxmeedrq55bpwm@treble> <20170808185809.qaug762cj7nw3bcd@treble> <20170808191344.kw5nlicmq4g6fpii@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.25]); Tue, 08 Aug 2017 22:00:52 +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 01:09:08PM -0700, Andy Lutomirski wrote: > >> 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. > > But this one's not an actual alternative, right? It's a pv op. Ah, right. Objtool doesn't know about paravirt patching, unfortunately. > I would advocate that we make it an alternative after all. I frickin' > hate the PV irq ops. It would like roughly like this: > > ALTERNATIVE "pushfq; popq %rax", "callq *pv_irq_ops.save_fl", > X86_FEATURE_GODDAMN_PV_IRQ_OPS > > (The obvious syntax error and the naming should probably be fixed. > Also, this needs to live in an #ifdef because it needs to build on > kernels with pv support. It should also properly register itself as a > pv patch site.) Yeah, that would be really nice, assuming it's possible. Otherwise I'll need to teach objtool about the paravirt patches. -- Josh