Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4281958imu; Fri, 30 Nov 2018 14:17:41 -0800 (PST) X-Google-Smtp-Source: AFSGD/XFQIhljdtUwfU2SYUXBsqMzJrgT4gjXNoF3utsKWj19koK+aY9q8JVr+0TX55h4o8rkfPO X-Received: by 2002:a17:902:346:: with SMTP id 64mr7509158pld.337.1543616261253; Fri, 30 Nov 2018 14:17:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543616261; cv=none; d=google.com; s=arc-20160816; b=zqYrxbWJxAtSncYyrp03YZsy3RX/kfkBcmHjUZkwpOjeu3FZWYBacn6onTp/1cFk73 3A5qTgnbMzLYLAH+7R8OcQAIgHvf/Sw+CV4rBtuEuL0ElHj4cq8F+oZlerbzoQSFUOvg lFZSSylZ+cpxlhlIY4sDc05DqxaVk7c96ZUgjtG6OEX3ynkQZCjFSG8krF8gzlNnHRtF PBupMN/pxLVjkPXtKSkOiH5aVxzukTbGp2xLW3h4IcbCoIBG5K/zzTyuRhEKrkw6Mqgv +EfPzP7F2UqezgFmF/UrT4A4fDUXgyCkbUVabfoHevKQbZzsq8hj55BmXgq0FlQLS6jz hADw== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=TgkXkZY9erwZj2thsjzh4ReMx12HiXtWD0UhwrUgdZE=; b=pqQcpi1QQVsedkspmSLlbA/wC+LqxJrZnXUNgFTXb2wkDmTKbZkTLEOozrdgpR3Xgu Yg8iCZMK4y6pHPNhtxoEU0BbLUtZBOn9sS+NRGwUuYcyhFv5L+N2G5XzoDpvgIr/5bZQ k1ajKXgcgkV6z4WGKKNBknzarcp9Tdmal/L9hSyuZTV3kh/5MVCiNx5ujcYuGbivr/jl VXrGFqXmEj42Q9J5MJII/rjdiK4iT0nzzUWihkVCet2AdO+bzW5bEt5BNwrOKspbymWL hlB2MLrJvsE44HPdGWh3ZPzi+gfiRNzFNmEn70RIJ/5Vitl9AgpEIAudWh2eB/2UGsFV rAgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=Cj5468or; 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 204si4356102pfu.273.2018.11.30.14.17.26; Fri, 30 Nov 2018 14:17:41 -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=pass header.i=@rasmusvillemoes.dk header.s=google header.b=Cj5468or; 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 S1726973AbeLAJ1Y (ORCPT + 99 others); Sat, 1 Dec 2018 04:27:24 -0500 Received: from mail-ed1-f66.google.com ([209.85.208.66]:36274 "EHLO mail-ed1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725749AbeLAJ1X (ORCPT ); Sat, 1 Dec 2018 04:27:23 -0500 Received: by mail-ed1-f66.google.com with SMTP id f23so6077209edb.3 for ; Fri, 30 Nov 2018 14:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TgkXkZY9erwZj2thsjzh4ReMx12HiXtWD0UhwrUgdZE=; b=Cj5468oraizKDKgTiISlsPqnO7wbH6tn1As9lPDdwkvSbaVu8s9NkFAVR+VdQ5pHll WMIc+TVAhsy4TdFPCNOyr0BID21JXmHPvqNp0/sUWgSDAC+1lkBq2BOZ7NwtRO0OPetL grq0NF52K0Wyf8YAc+vEKpWPPcRbMiEua67u0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TgkXkZY9erwZj2thsjzh4ReMx12HiXtWD0UhwrUgdZE=; b=s3gf6LCOmr6AN7jvUXmB4VXFBH3k/RqVPqjds9qp15tOSgrdNhAQ43Y6SQPRVAyhue SVU7O/iiKmfpTVFqfq5TiGEKGyUtL3VUivN7qJkeOx7PwsCH+BQBHY6CnUMv4HzyowbR UZ7ghsSETrM4dr4gf29G8mRfdpl/tL3M4iyhxzrglIcpJw0WNTJwXUKBMie6CErXKtsP /1DWNU9V5Anl8yberfNT9FPN59FlugDpQ9TG9XCb6581fDk3MCEDP5lSIMoPecDz2ZRF LdT7q95CCpHoDQNttZ8K43hVE00aAtjIbzjj1o9T22NwTTKwQI71GddMniNlpWcUw/Wv Xj9Q== X-Gm-Message-State: AA+aEWYuKJ4rmt0vJtztvwrPuYFlBUk4fBnHpjvGdQhJ/wzSsaygUGYE 2vRk7n2RMtVZza+MgLOR85dFOA== X-Received: by 2002:a50:b172:: with SMTP id l47mr6510989edd.225.1543616196410; Fri, 30 Nov 2018 14:16:36 -0800 (PST) Received: from [192.168.0.189] (ip-5-186-114-252.cgn.fibianet.dk. [5.186.114.252]) by smtp.gmail.com with ESMTPSA id 97sm1717861edq.45.2018.11.30.14.16.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Nov 2018 14:16:35 -0800 (PST) Subject: Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64 To: Josh Poimboeuf , Steven Rostedt Cc: Linus Torvalds , Andy Lutomirski , Peter Zijlstra , Andrew Lutomirski , the arch/x86 maintainers , Linux List Kernel Mailing , Ard Biesheuvel , Ingo Molnar , Thomas Gleixner , mhiramat@kernel.org, jbaron@akamai.com, Jiri Kosina , David.Laight@aculab.com, bp@alien8.de, julia@ni.com, jeyu@kernel.org, Peter Anvin References: <0A629D30-ADCF-4159-9443-E5727146F65F@amacapital.net> <20181129121307.12393c57@gandalf.local.home> <20181129124404.2fe55dd0@gandalf.local.home> <20181129125857.75c55b96@gandalf.local.home> <20181129134725.6d86ade6@gandalf.local.home> <20181129141648.6ef944a9@gandalf.local.home> <20181129192211.ndzj2ltzx5t6x2qe@treble> From: Rasmus Villemoes Message-ID: Date: Fri, 30 Nov 2018 23:16:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181129192211.ndzj2ltzx5t6x2qe@treble> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/11/2018 20.22, Josh Poimboeuf wrote: > On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote: >>> and honestly, the way "static_call()" works now, can you guarantee >>> that the call-site doesn't end up doing that, and calling the >>> trampoline function for two different static calls from one indirect >>> call? >>> >>> See what I'm talking about? Saying "callers are wrapped in macros" >>> doesn't actually protect you from the compiler doing things like that. >>> >>> In contrast, if the call was wrapped in an inline asm, we'd *know* the >>> compiler couldn't turn a "call wrapper(%rip)" into anything else. >> >> But then we need to implement all numbers of parameters. > > I actually have an old unfinished patch which (ab)used C macros to > detect the number of parameters and then setup the asm constraints > accordingly. At the time, the goal was to optimize the BUG code. > > I had wanted to avoid this kind of approach for static calls, because > "ugh", but now it's starting to look much more appealing. > > Behold: > > diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h > index aa6b2023d8f8..d63e9240da77 100644 > --- a/arch/x86/include/asm/bug.h > +++ b/arch/x86/include/asm/bug.h > @@ -32,10 +32,59 @@ > > #ifdef CONFIG_DEBUG_BUGVERBOSE > > -#define _BUG_FLAGS(ins, flags) \ > +#define __BUG_ARGS_0(ins, ...) \ > +({\ > + asm volatile("1:\t" ins "\n"); \ > +}) > +#define __BUG_ARGS_1(ins, ...) \ > +({\ > + asm volatile("1:\t" ins "\n" \ > + : : "D" (ARG1(__VA_ARGS__))); \ > +}) > +#define __BUG_ARGS_2(ins, ...) \ > +({\ > + asm volatile("1:\t" ins "\n" \ > + : : "D" (ARG1(__VA_ARGS__)), \ > + "S" (ARG2(__VA_ARGS__))); \ > +}) > +#define __BUG_ARGS_3(ins, ...) \ > +({\ > + asm volatile("1:\t" ins "\n" \ > + : : "D" (ARG1(__VA_ARGS__)), \ > + "S" (ARG2(__VA_ARGS__)), \ > + "d" (ARG3(__VA_ARGS__))); \ > +}) wouldn't you need to tie all these to (unused) outputs as well as adding the remaining caller-saved registers to the clobber list? Maybe not for the WARN machinery(?), but at least for stuff that should look like a normal call to gcc? Then there's %rax which is either a clobber or an output, and if there's not to be a separate static_call_void(), one would need to do some __builtin_choose_expr(__same_type(void, f(...)), ...). Rasmus