Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1013811imu; Fri, 11 Jan 2019 13:17:26 -0800 (PST) X-Google-Smtp-Source: ALg8bN4QnN5jFEP/rSKYMFq3ntMNYqU14+08P6y6M3oY5mDEEhNjPuR9RcO7E6omGQQaBr3N2Obh X-Received: by 2002:a62:6ec8:: with SMTP id j191mr16146120pfc.198.1547241446920; Fri, 11 Jan 2019 13:17:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547241446; cv=none; d=google.com; s=arc-20160816; b=BOsDXNQLskFLDwRETrOmy36It2p+1S9KmByWE0sjKtZ8CGW71u82Oys8XIr7JvuY5u oLjtExJI8pYIhF6SL7CdMdYdflFk/k3d4oT02w8WlicVTi68hO5r+5XOv7aZZXbsWais cou+k+ogUzEdPPXl+Au9JqoKAK+rEpwdeJQBuwUTHTjeabnM6nKe4u9Druu13giW47tO 7FKv8f+FvZzxDECICNGCrSel+43ifiP83bioTfFokNkC59vUvrfih94EN9o0lYE5blLo PJZNv85es+IobunfetDLW7t8frPJxYFHUs9othqXiP4QOV/UHF4+XVoPwxzSvAejrSfo 1Q2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=/hT7UKY+G2ySYPgBgkyBknVVdA2+679pMe1OFlfFU48=; b=pzQ9v5IWiRPKvBvBbEYc2n4RV9fBmopY3ySMNK/tlsTrpbvj37kCBMWsTn8II6vaFk oWKvOYj1p/GIPkvTHOLshAi8gzXon237mUeGUiEhgzF4Xc7piCG0Tuu42ClkB8ip/2Tj hz/GAhz0+1mxDTLUq50qULiHTbB8YFnMByBLOeNOBciytxfRkJzf2q2SWgQSWPAo/JWu ahFJo24wjIzpiiKSXp4GVglG4qzPfJdOZ6DGmZ8uf6lhYnfz7aO5mtpH4N1XaOEKlvjT aeoNVQO5VUL8cKRgPK1Nj1KbP4JNrSqR+xjRpPmW1B09HMStN4B6NKtZA3JsOqPXj+Im yyKw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p11si2200053plo.363.2019.01.11.13.17.11; Fri, 11 Jan 2019 13:17:26 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390778AbfAKUbn (ORCPT + 99 others); Fri, 11 Jan 2019 15:31:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34902 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389191AbfAKUbm (ORCPT ); Fri, 11 Jan 2019 15:31:42 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B8056FD3DF; Fri, 11 Jan 2019 20:31:41 +0000 (UTC) Received: from treble (ovpn-122-231.rdu2.redhat.com [10.10.122.231]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 454AB1001F50; Fri, 11 Jan 2019 20:31:37 +0000 (UTC) Date: Fri, 11 Jan 2019 14:31:35 -0600 From: Josh Poimboeuf To: Linus Torvalds Cc: Nadav Amit , Andy Lutomirski , Peter Zijlstra , the arch/x86 maintainers , Linux List Kernel Mailing , Ard Biesheuvel , Steven Rostedt , Ingo Molnar , Thomas Gleixner , Masami Hiramatsu , Jason Baron , Jiri Kosina , David Laight , Borislav Petkov , Julia Cartwright , Jessica Yu , "H. Peter Anvin" , Rasmus Villemoes , Edward Cree , Daniel Bristot de Oliveira Subject: Re: [PATCH v3 0/6] Static calls Message-ID: <20190111203135.5clurevf34bkiy3o@treble> References: <20190110203023.GL2861@worktop.programming.kicks-ass.net> <20190110205226.iburt6mrddsxnjpk@treble> <20190111151525.tf7lhuycyyvjjxez@treble> <20190111200420.qtyffayxceysoarf@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 11 Jan 2019 20:31:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 11, 2019 at 12:12:30PM -0800, Linus Torvalds wrote: > On Fri, Jan 11, 2019 at 12:04 PM Josh Poimboeuf wrote: > > > > But really, to me, having to create and manage all those custom > > trampolines still feels a lot more complex than just making a gap on the > > stack. > > There are no "all those custom trampolines". > > There is literally *one* custom trampoline that you generate as you do > the rewriting. > > Well, two, since you need the version with the "sti" before the jmp. > > It would be possible to generate the custom trampoline on the fly in > the BP handler itself, and just have a magic flag for that case. But > it's probably simpler to do it in the caller, since you need to > generate that special writable and executable code sequence. You > probably don't want to do that at BP time. > > You probably want to use a FIX_TEXT_POKE2 page for the generated > sequence that just maps some generated code executably for a short > while. Or something like that. I was referring to the fact that a single static call key update will usually result in patching multiple call sites. But you're right, it's only 1-2 trampolines per text_poke_bp() invocation. Though eventually we may want to batch all the writes like what Daniel has proposed for jump labels, to reduce IPIs. Regardless, the trampoline management seems more complex to me. But it's easier to argue about actual code, so maybe I'll code it up to make it easier to compare solutions. -- Josh