Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3656055imu; Sun, 11 Nov 2018 20:40:43 -0800 (PST) X-Google-Smtp-Source: AJdET5edsC0+g+4rTQCmptV6at+1jVntc0HhVNfc1iM1JFiquc/NXGh5ClbmFlIgo8niioMS0BiM X-Received: by 2002:a65:4244:: with SMTP id d4-v6mr16178939pgq.289.1541997643615; Sun, 11 Nov 2018 20:40:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541997643; cv=none; d=google.com; s=arc-20160816; b=RMu+YPgQK5mjtToQebZBFwL+YOdcUF07MK9K8kjoapFkatQjhnxFBhhOYgK2Vzfrgm jYmaBtqRABD7M4NsbraTjrQwxuHHraSgRQCcJz/k0AwBFyDLWLE04wuwH85vFVCQvPnE 9pQlVVeNgZ2xW2cQDdk42RVxt3q6wm6F5fHLTKTQKAcygitfZhTNYwNv7fcFQe9U1jhl 7vCuOMYZxxeMw/eI5owfNJHkAwaLK4qYbWmS/y87or3KybGqmfOxvvVDkjojxE2RUf7d KOLJKn1UG2ZUTd98NQUGVpZhuDsFF7Et7bouS/c8hWXKE+xoJW58w8FkPt1W1D1lha7m Jv1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=ZjTRt0DT4A2OzPKlOCPUzd9PMvVAmqa/3ubknwqW0N4=; b=PLWFKh9fbFBKDZ9j8M15p0QzcTZeToNn3JfkMEls+k7PvhLJHVg1cOoftjfDik1iqr gXJU1jrCGhq1bvfPHH1gXydtEo5/+tkzFTSzRVEtt9x+jQjT+XsK8wPSjP8CTFJ7y0Z2 k9sRqWrRsqqbAgTw1RTjcYaGywV7t3WLppsA2uf8WKJ6+/POnFCkB0ZUIFzyqu3siyvP xm+73fj+0WW4wxCteAmQuOuY24AaIdVA3T/75/estTrmjp6jbNX28qXH14157LXEOs/7 R/AghmLxRirwrHlZefwMT4wa620kCXtBGvQWPHHXewdes9FhuV6gWg07mX9Kl3ls7yHr k+kA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=TwOpg9fw; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s6-v6si6408701plp.139.2018.11.11.20.40.11; Sun, 11 Nov 2018 20:40:43 -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=@linaro.org header.s=google header.b=TwOpg9fw; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728135AbeKLObF (ORCPT + 99 others); Mon, 12 Nov 2018 09:31:05 -0500 Received: from mail-it1-f193.google.com ([209.85.166.193]:54600 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727597AbeKLObF (ORCPT ); Mon, 12 Nov 2018 09:31:05 -0500 Received: by mail-it1-f193.google.com with SMTP id a205-v6so5242547itd.4 for ; Sun, 11 Nov 2018 20:39:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZjTRt0DT4A2OzPKlOCPUzd9PMvVAmqa/3ubknwqW0N4=; b=TwOpg9fwK0sUwHrlnuv5LGdZcq3VQXm1xP53pEKk0cEFeKcFaFHMhefspNYGWX1lg3 YUXUlXCq8KPxH9OHS3HgK5aKrYte9PrAIGq9y1dcF6M1zpbqFjtZEl0pDg9+fB0UJQMp aW8PrTW7ZEzyd37PAZK5a9epxoBignyok6MwM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZjTRt0DT4A2OzPKlOCPUzd9PMvVAmqa/3ubknwqW0N4=; b=QB9JNFO6ISx7DZPS/Nal9EWxH15vRLK8kgXKWh1qyae2YRLEtGCJzuL8uKnpPBbuYQ Fyoso8I1jEc+VXipTuu4DQnOh/pDr24IVF2tlsow/LHM9ulPrbtMyR+oMUH6kO3zkUJY VTgkgzjAnIYhSkKpz3yD+w1F04/CKZKoEL5NuMedUVtRfdspzAo9+yr/af1kCD87UK6V 17jpTSd6NOXoUU4cuNX8j1/nY92Bg0kQMitS2u2rZCCK4vSXl7FNyr4EHRpeRHp8qXCr gPDC42ZPCpjh7BuT2hlMCijqcugYfp+mzaej6McNF56JYzjib15iXLbfsJFLBxn0hELy KZ0Q== X-Gm-Message-State: AGRZ1gLj/e9IpwgYZa/84cUsUMi7BgGCpwHNLgwsqpR8KLwTCoRCFKgP 9Vm2Am88bCiRhFqCnVVe2L8CWSDZ3n5qjk9r4QCyyLzf X-Received: by 2002:a24:2190:: with SMTP id e138-v6mr10878636ita.71.1541997579135; Sun, 11 Nov 2018 20:39:39 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a6b:4f16:0:0:0:0:0 with HTTP; Sun, 11 Nov 2018 20:39:38 -0800 (PST) In-Reply-To: <20181112030722.da5cxslvlmdgttsw@treble> 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> <20181110080917.29af5d66@vmware.local.home> <20181112030722.da5cxslvlmdgttsw@treble> From: Ard Biesheuvel Date: Mon, 12 Nov 2018 05:39:38 +0100 Message-ID: Subject: Re: [RFC PATCH 1/3] static_call: Add static call infrastructure To: Josh Poimboeuf Cc: Steven Rostedt , 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 Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12 November 2018 at 04:07, Josh Poimboeuf wrote: > On Sat, Nov 10, 2018 at 08:09:17AM -0500, Steven Rostedt wrote: >> 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. > > Yes, DECLARE needs the __ADDRESSABLE. In the case where DECLARE > is used, but DEFINE is not, GCC strips the symbol. > I assume DECLARE() is intended for use in header files, and DEFINE() for source files, no? Doesn't that mean that whatever symbol __ADDRESSABLE() refers to should have external linkage, in which case it it addressable anyway? Or are we talking about some LTO / --gc-sections use case here? >> 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) > > Adding __ADDRESSABLE to the DEFINE macro doesn't do any good. By > definition, the key is defined in the .o file, so the symbol already > exists. > > The issue you're seeing is really an issue with the __ADDRESSABLE macro > not creating unique symbol names. This should fix it: > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h > index 06396c1cf127..4bb73fd918b5 100644 > --- a/include/linux/compiler.h > +++ b/include/linux/compiler.h > @@ -282,7 +282,7 @@ unsigned long read_word_at_a_time(const void *addr) > */ > #define __ADDRESSABLE(sym) \ > static void * __section(".discard.addressable") __used \ > - __PASTE(__addressable_##sym, __LINE__) = (void *)&sym; > + __UNIQUE_ID(__addressable_##sym) = (void *)&sym; > > /** > * offset_to_ptr - convert a relative memory offset to an absolute pointer Not sure if it matters, but we'll end up with a lot more stuff in .discard.addressable this way.