Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp49332imu; Mon, 26 Nov 2018 07:49:19 -0800 (PST) X-Google-Smtp-Source: AJdET5eQf4Xiz/x/XggwDqxb6jXGnFsBx3+WyBAJfAwhIQpQld87Z3JUoFiO4PeFg0V4qfTGs/6M X-Received: by 2002:a62:ae12:: with SMTP id q18mr28637698pff.126.1543247359539; Mon, 26 Nov 2018 07:49:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543247359; cv=none; d=google.com; s=arc-20160816; b=SBS0Psl6Dum+Kc1phw+zeQg86A+NOtBudyRt4Haaw9squNGdOUMhgXiaod2WZUy5pd M5HP6MtMCjZjOtfgXYZiZ6OHAGsnudYkCcTwBjzIJXD9ETmqau+DuutZbP+4fQa3OmEI rCNxHnPi4X7lVtf5XHbGJrvnLPZlCN8opbxaOCSqUd8GddxjM2/65Zh4c4FDf6GHD+Ia 2uLgBt6ARQLGo+5CMI80BBz+jCANjJPOveWpz540+cLONhEi0TVOfVkuQaKvf9Y9CR7V 1+YJUwY6Zx+E7XYdIGtLiPdvGdiYiajgIoUEx6epVTSu7Kmqbb3LNOEn8b3+59FseGip A5kw== 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:dkim-signature; bh=1DM+dmTlWTm0n9zlOsjVXVHDGYx1jlvwMsMNEHfEBQo=; b=i45B19SsnOXHg0rYKYs9C/rVX3IkRM6c5lEC+yT7eYw86ik6X0tBp7ykh/7B5D5S7U DbbqwGvCyB/8XIRIwEE6U0RML6AatTetFkFj+xFgbw0ESTdovc0aNLcu6oKZo24l2dXu Dipaq/YVfkizIkUpTZqXVPf2UkCaRzLjJHygZh1eietr32SsvH6HIkanqu6oWnwghhtU aop3tiipUHIcWDBtVQI8MPe1ZatnF21js6/qdeXKczjj+Rt8nLtrezSoBE+0koskmrN9 pfKj9y3vgkjBrKgCcaQzq2P4jNSxMEpDgagBGkk93vUEb5p7tKu2A/tXqXyq2pRbgqUY gUKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=OJcG99cv; 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 r1-v6si662084plb.153.2018.11.26.07.48.22; Mon, 26 Nov 2018 07:49:19 -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; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=OJcG99cv; 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 S1726507AbeK0Cir (ORCPT + 99 others); Mon, 26 Nov 2018 21:38:47 -0500 Received: from merlin.infradead.org ([205.233.59.134]:39498 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726167AbeK0Ciq (ORCPT ); Mon, 26 Nov 2018 21:38:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1DM+dmTlWTm0n9zlOsjVXVHDGYx1jlvwMsMNEHfEBQo=; b=OJcG99cvOyL/PXLgOGyL0T8/S 471RzsiSKAGKONutVr6riulxjXHZoxTDNqgdDUcxKbPWfX2bt1sXj/d0QAQKXBMSBhpSZP6V1N/7X Nt0Oqlcc++dFdWmjBmrXJMhcw/blUvvIsaot5FIEge16MddMk3iLmeq/vqp0S1EaduKxodZvKww5c sdhxPcUEheRLr7zTv+OX9uThySXMFBtpAGsC84ioc/RAjs/tW6ZWNKT28C2YAkuyoPR9wYMMs5LLY tXzvzfAcGcoy783Rse+caATdanmYj3RKxEUhgtWx/E8Qpeq4mbNYKTR47VDn+lAnjFIEnzZHHm4Ol HZx7PZEsA==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1gRJ3F-0001a3-Ud; Mon, 26 Nov 2018 15:43:58 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 31D9D2029FD58; Mon, 26 Nov 2018 16:43:56 +0100 (CET) Date: Mon, 26 Nov 2018 16:43:56 +0100 From: Peter Zijlstra To: Josh Poimboeuf Cc: x86@kernel.org, linux-kernel@vger.kernel.org, Ard Biesheuvel , Andy Lutomirski , Steven Rostedt , Ingo Molnar , Thomas Gleixner , Linus Torvalds , Masami Hiramatsu , Jason Baron , Jiri Kosina , David Laight , Borislav Petkov , Julia Cartwright , Jessica Yu , "H. Peter Anvin" Subject: Re: [PATCH v2 3/4] x86/static_call: Add out-of-line static call implementation Message-ID: <20181126154356.GP2113@hirez.programming.kicks-ass.net> References: <00b08f2194e80241decbf206624b6580b9b8855b.1543200841.git.jpoimboe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b08f2194e80241decbf206624b6580b9b8855b.1543200841.git.jpoimboe@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 26, 2018 at 07:54:59AM -0600, Josh Poimboeuf wrote: > +void static_call_bp_handler(void); > +void *bp_handler_dest; > + > +asm(".pushsection .text, \"ax\" \n" > + ".globl static_call_bp_handler \n" > + ".type static_call_bp_handler, @function \n" > + "static_call_bp_handler: \n" > + "ANNOTATE_RETPOLINE_SAFE \n" > + "jmp *bp_handler_dest \n" > + ".popsection \n"); > + > +void arch_static_call_transform(void *site, void *tramp, void *func) > +{ > + s32 dest_relative; > + unsigned long insn; > + unsigned char insn_opcode; > + unsigned char opcodes[CALL_INSN_SIZE]; > + > + insn = (unsigned long)tramp; > + > + mutex_lock(&text_mutex); > + > + insn_opcode = *(unsigned char *)insn; > + if (insn_opcode != 0xe8 && insn_opcode != 0xe9) { > + WARN_ONCE(1, "unexpected static call insn opcode 0x%x at %pS", > + insn_opcode, (void *)insn); > + goto done; > + } > + > + dest_relative = (long)(func) - (long)(insn + CALL_INSN_SIZE); > + > + opcodes[0] = insn_opcode; > + memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1); > + > + /* Set up the variable for the breakpoint handler: */ > + bp_handler_dest = func; > + > + /* Patch the call site: */ > + text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE, > + static_call_bp_handler); I'm confused by the whole static_call_bp_handler thing; why not jump straight to @func ? Also, what guarantees this other thread will have gotten from static_call_bp_handler and executed the actual indirect JMP instruction by the time we re-write @bp_handler_dest again? > +done: > + mutex_unlock(&text_mutex); > +}