Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5175220ybv; Mon, 17 Feb 2020 14:03:26 -0800 (PST) X-Google-Smtp-Source: APXvYqxcqLHwzvbNQIOtIiWeTZOcZ59mtT1Dibf/cv3s6+DbAbk+W8c2hOuunEnRkWYcnDnqLorj X-Received: by 2002:aca:ab52:: with SMTP id u79mr658630oie.145.1581977006301; Mon, 17 Feb 2020 14:03:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581977006; cv=none; d=google.com; s=arc-20160816; b=iL94pU8liiYoj+ujDI7O8KyvjDzXlarZJ5zq9eQOKG76JdODDKxfd5TTkJr8M0lVtz MZ9o8oMQfBkAeek/fo3ULolFcxVE5waMZN2ptVClq1S5lFZKLJmOm3SW8el2ea02Nc0X IsCA1j0zjE1IioLUNGftPMFp19sebHSCN0sOMAXwuqukxB6LN3HZmAe4kYU1zyg2sUpW bfAShavHc7v0vivv+nyoNqykbnOVdaGuTKADLy1mC9DDOAM0oRXdqXnErBwIbtBHi53J dehHnMonCCzox4SD38DIfJt+S1psq5LkIGQb6Po1bErm5zeoBbmaGIPYuEBA6AsbmjH0 yYNw== 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=UhGMgbbeQAJG5WBi9J//5ADCVNXTSR9o9cD8Ej8MQuw=; b=iiy/rtWg/DbpHxR2c9sTxFrKuCIe7xQBhNiNOZSLHkUorBxXKofsqEaGb6GQ3PLwpr 7UH/ZvRbU4SwjgET3Nd976gbAnkMvv9j0uz6JHj+Z5HcMUFC/K65GbpzbNlFrWCWVX/4 cI6xxffZMWhR0UOibwyHG3b4/gw3RoBOdau23xKBRenXdbBQ1DdzacwRGEbZA7T0SfCD lNeTAu/bySQlzTFJuqrQaFhJ79W6DGdG/rCnuFhhnVX+RpFPivtPQRmFR1VozCRin4q3 Z5RizAl/jrOyRXaKZ/BT+kb0mg4PRBOp2ETx9RXfRNkxHlpLVqH6wtpEz1xjLGauG1ii /wgA== 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 p16si843736oto.287.2020.02.17.14.03.14; Mon, 17 Feb 2020 14:03: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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730024AbgBQV5S (ORCPT + 99 others); Mon, 17 Feb 2020 16:57:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:43534 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729558AbgBQV5S (ORCPT ); Mon, 17 Feb 2020 16:57:18 -0500 Received: from gandalf.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 1E3232064C; Mon, 17 Feb 2020 21:57:16 +0000 (UTC) Date: Mon, 17 Feb 2020 16:57:14 -0500 From: Steven Rostedt To: Jann Horn Cc: Josh Poimboeuf , Peter Zijlstra , "the arch/x86 maintainers" , kernel list , Ard Biesheuvel , Andy Lutomirski , Ingo Molnar , Thomas Gleixner , Linus Torvalds , Masami Hiramatsu , Jason Baron , Jiri Kosina , David Laight , Borislav Petkov , Julia Cartwright , Jessica Yu , "H. Peter Anvin" , Nadav Amit , Rasmus Villemoes , Edward Cree , Daniel Bristot de Oliveira Subject: Re: [PATCH v3 0/6] Static calls Message-ID: <20200217165714.1080cfd2@gandalf.local.home> In-Reply-To: References: <20190110203023.GL2861@worktop.programming.kicks-ass.net> <20190110205226.iburt6mrddsxnjpk@treble> 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, 17 Feb 2020 22:10:27 +0100 Jann Horn wrote: > On Thu, Jan 10, 2019 at 9:52 PM Josh Poimboeuf wrote: > > On Thu, Jan 10, 2019 at 09:30:23PM +0100, Peter Zijlstra wrote: > > > On Wed, Jan 09, 2019 at 04:59:35PM -0600, Josh Poimboeuf wrote: > > > > With this version, I stopped trying to use text_poke_bp(), and instead > > > > went with a different approach: if the call site destination doesn't > > > > cross a cacheline boundary, just do an atomic write. Otherwise, keep > > > > using the trampoline indefinitely. > > > > > > > - Get rid of the use of text_poke_bp(), in favor of atomic writes. > > > > Out-of-line calls will be promoted to inline only if the call sites > > > > don't cross cache line boundaries. [Linus/Andy] > > > > > > Can we perserve why text_poke_bp() didn't work? I seem to have forgotten > > > again. The problem was poking the return address onto the stack from the > > > int3 handler, or something along those lines? > > > > Right, emulating a call instruction from the #BP handler is ugly, > > because you have to somehow grow the stack to make room for the return > > address. Personally I liked the idea of shifting the iret frame by 16 > > bytes in the #DB entry code, but others hated it. > > > > So many bad-but-not-completely-unacceptable options to choose from. > > Silly suggestion from someone who has skimmed the thread: > > Wouldn't a retpoline-style trampoline solve this without needing > memory allocations? Let the interrupt handler stash the destination in > a percpu variable and clear IF in regs->flags. Something like: Linus actually suggested something similar, but for ftrace, but after implementing it, it was hard to get right, and caused havoc with utilities like lockdep, and also shadow stacks. See this thread: https://lore.kernel.org/linux-kselftest/CAHk-=wh5OpheSU8Em_Q3Hg8qw_JtoijxOdPtHru6d+5K8TWM=A@mail.gmail.com/ -- Steve