Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1957803imu; Sat, 10 Nov 2018 05:10:38 -0800 (PST) X-Google-Smtp-Source: AJdET5e3uYxziEzmzxdmwRxh8gSeENCMEQVy6oj5BFkvkooEXc5gwvpw2hToMIErAG6ueCjq1LOA X-Received: by 2002:a62:b24e:: with SMTP id x75-v6mr13238446pfe.148.1541855438635; Sat, 10 Nov 2018 05:10:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541855438; cv=none; d=google.com; s=arc-20160816; b=hwUdEeTzWABRWL7KRAcarJnJFuw2Z3MMC2QxqR9h78pdHgmb8qx17Er/1oByKQuJFi oSbNfuJoAnwVcq68xyWWieJI03W6uWy2zcnIsViY3MZ6GWwqhJ8j2jl6y/76Low/0GB1 CCZgr4f1uwZI9NTUFpu06MoD4jzyLZJUxuWiT0J05E7ENo7oyOnVSLG0jbSb/A902+hV D3EaNVPu3pq01GB/sbuf2uMtAS2t21B344ujzjq4GL8kKs2hENMr90ojvU6+kLc0L0jR +5Lut5vXgVG1NHlQaQ0LIVZFlcdAmnIsuPUBbkhyWokURfdF7DJ13NZUS2tB8yGnEBl7 z1cg== 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=ZfuR1rYh4DZM+ConKcdgeLq31FWNem4Op4zuojCAvTY=; b=ep43juh6QoQNQud7vLGD5HXjAn4lKMPHnsZKuBZCxoFllJwFtSnsuaSpkP8o6iLVeT xM5yfNz8JcDS3+ydpZEkPPUZCLRF4ihF8sbT/co8sLH3gCPtZVUiGG6E6ippeouHPLv5 DasqDL6BUcswsUkc3a6LtbuPKrL5ly+ip7bQvH4lYQjIdBsWgicoH0c9cagoi6xvTLq1 P9rRypkY5A+yH3lmt00fZs5zneizUXC1gyecH/BrpX+R2e823g27S8wVJENM63t+0nZL P94yNLzs4rXJaCtnoH5EkFFdwiYPVw8E3w2PHhLkwoLV99uYGCnuiPxSTNxdK0zF3R/n TOSQ== 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 s132-v6si10375871pgs.492.2018.11.10.05.10.22; Sat, 10 Nov 2018 05:10:38 -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 S1729061AbeKJWyT (ORCPT + 99 others); Sat, 10 Nov 2018 17:54:19 -0500 Received: from mail.kernel.org ([198.145.29.99]:49580 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728996AbeKJWyT (ORCPT ); Sat, 10 Nov 2018 17:54:19 -0500 Received: from vmware.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (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 B399720854; Sat, 10 Nov 2018 13:09:19 +0000 (UTC) Date: Sat, 10 Nov 2018 08:09:17 -0500 From: Steven Rostedt To: Ard Biesheuvel Cc: Josh Poimboeuf , Linux Kernel Mailing List , "the arch/x86 maintainers" , Andy Lutomirski , Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Linus Torvalds , Masami Hiramatsu , Jason Baron , Jiri Kosina , David Laight , Borislav Petkov Subject: Re: [RFC PATCH 1/3] static_call: Add static call infrastructure Message-ID: <20181110080917.29af5d66@vmware.local.home> In-Reply-To: References: <3cf04e113d71c9f8e4be95fb84a510f085aa4afa.1541711457.git.jpoimboe@redhat.com> <20181109133337.63487e3a@gandalf.local.home> <20181109193505.5p5iddrtgpk2cpb4@treble> <20181109145746.0037da3f@gandalf.local.home> <20181109203459.wbftlkxcvfnwo2bm@treble> <20181110001023.57f27312@vmware.local.home> X-Mailer: Claws Mail 3.15.1 (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 Sat, 10 Nov 2018 12:58:08 +0100 Ard Biesheuvel wrote: > > The complaint is on: > > > > DEFINE_STATIC_CALL(__tp_func_##name, __tracepoint_iter_##name); > > > > And the previous definition is on: > > > > DECLARE_STATIC_CALL(__tp_func_##name, __tracepoint_iter_##name); \ > > > > Does the DECLARE really need the __ADDRESSABLE? Its purpose is to > ensure that symbols with static linkage are not optimized away, but > since the reference is from a header file, the symbol should have > external linkage anyway. I applied the following change and it compiled fine: diff --git a/include/linux/static_call.h b/include/linux/static_call.h index 90b580b95303..5f8a0f0e77be 100644 --- a/include/linux/static_call.h +++ b/include/linux/static_call.h @@ -108,8 +108,6 @@ extern void arch_static_call_poison_tramp(unsigned long insn); #define DECLARE_STATIC_CALL(key, func) \ extern struct static_call_key key; \ extern typeof(func) STATIC_CALL_TRAMP(key); \ - /* Preserve the ELF symbol so objtool can access it: */ \ - __ADDRESSABLE(key) #define DEFINE_STATIC_CALL(key, _func) \ DECLARE_STATIC_CALL(key, _func); \ @@ -117,7 +115,9 @@ extern void arch_static_call_poison_tramp(unsigned long insn); .func = _func, \ .site_mods = LIST_HEAD_INIT(key.site_mods), \ }; \ - ARCH_STATIC_CALL_TEMPORARY_TRAMP(key) + ARCH_STATIC_CALL_TEMPORARY_TRAMP(key); \ + /* Preserve the ELF symbol so objtool can access it: */ \ + __ADDRESSABLE(key) #define static_call(key, args...) STATIC_CALL_TRAMP(key)(args) Thanks! -- Steve