Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1141661imu; Fri, 9 Nov 2018 11:36:43 -0800 (PST) X-Google-Smtp-Source: AJdET5d/z4wV4vH3+I3mqS1z/swgIDVlyyy6jTqgHhXoUKx5qU7FNxwc4iPlw08Vob4HJjOqoIlP X-Received: by 2002:a63:8441:: with SMTP id k62mr2707624pgd.392.1541792203720; Fri, 09 Nov 2018 11:36:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541792203; cv=none; d=google.com; s=arc-20160816; b=Sgs6lCHQte4yXZPZcRU7kuhH+NxHqev2BpcOgZmbZutCfhgqeXVZLHyZLNub6V2Pgd fh+sz347DTonYrlvpoKfpeWVHwzV4CH/HyJ84G1/V4qwMxGSWbIbjMoFM48ZIEHmVV3Y aZqT9F2OUvPx2t+izMGDEPcFrMUl4rmhn5KmNZjv1FitHklhOtDMtYuKD+o1ednS6pYX B4Y95oBXDET2n1ZCwVi6joWQBC3qBYcR5jLBHcsEo3AgHOa4Mdn0KlfT+xwFNYRPHl/l egqp6b3tDAFCa0rooLNONzjIbOXutCa/94ABTKpxZnyGUQytHCow0G1IHcV3ZVB0Innw bOKg== 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; bh=exty3ga2AwmSEv9I6bcUekUl6YO+0lq6Nlw5+07+0mg=; b=IBtTk/x7DcGi0qZr5q4InKq6G+EDTMNwj1iQL/Nk7XdST8cYD81FVTvMb6WtFcEyER V46zcelt6ljNzYN8Vi2dQ5zaXQaZhqRplZaPkJo7K+EgeEQGq7qfpJMnOzjwSgyOcQ0T gMd70aF2j6nsUfYSujs6t70TUKy9BYLtnOxZf8pjhG0o4OWqSyPYminca/yfKu9is5e+ UsfTHQFsygdDwXJX18wCUNO974Sbt+SdisCiZzIm8fRS85joML4IDmZBR+UuPSHca9IC 8henbeXGyTIE/COY2nzZhlQ/rzh/OTmUUImGGzUTDq5UsrKC6JwWUo8YL+zXsmNJzXRR 9xmw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n33si6722287pgl.336.2018.11.09.11.36.25; Fri, 09 Nov 2018 11:36: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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726572AbeKJFRJ (ORCPT + 99 others); Sat, 10 Nov 2018 00:17:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48218 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725768AbeKJFRJ (ORCPT ); Sat, 10 Nov 2018 00:17:09 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4E05B308212C; Fri, 9 Nov 2018 19:35:09 +0000 (UTC) Received: from treble (ovpn-124-61.rdu2.redhat.com [10.10.124.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 11A4E600CD; Fri, 9 Nov 2018 19:35:06 +0000 (UTC) Date: Fri, 9 Nov 2018 13:35:05 -0600 From: Josh Poimboeuf To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, x86@kernel.org, Ard Biesheuvel , 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: <20181109193505.5p5iddrtgpk2cpb4@treble> References: <3cf04e113d71c9f8e4be95fb84a510f085aa4afa.1541711457.git.jpoimboe@redhat.com> <20181109133337.63487e3a@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20181109133337.63487e3a@gandalf.local.home> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Fri, 09 Nov 2018 19:35:09 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 09, 2018 at 01:33:37PM -0500, Steven Rostedt wrote: > > +config HAVE_STATIC_CALL_OPTIMIZED > > + bool > > + > > +config HAVE_STATIC_CALL_UNOPTIMIZED > > + bool > > + > > Let's also have > > config HAVE_STATIC_CALL > def_bool Y > depends on HAVE_STATIC_CALL_OPTIMIZED || HAVE_STATIC_CALL_UNOPTIMIZED > > > +#if defined(CONFIG_HAVE_STATIC_CALL_OPTIMIZED) || \ > > + defined(CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED) > > Now we can have: > > #ifdef CONFIG_HAVE_STATIC_CALL Yeah, that's better. > > +#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) > > Does the __ADDRESSABLE(key) need to be in the DECLARE part? > If so, there needs to be more explanation than just the comment above > it. For each call site, objtool creates a struct in .static_call_sites: struct static_call_site { s32 addr; s32 key; }; In order to do that, it needs to create a relocation which references the key symbol. If the key is defined in another .o file, then the current .o will not have an ELF symbol associated with the key. The __ADDRESSABLE(key) thing tells GCC to leave the key symbol in the .o file, even though it's not referenced anywhere. That makes objtool's job easier, so it doesn't have to edit the symbol table. I could add a comment saying as much, though it's hard to explain it in fewer words than I just did :-) > > + /* > > + * If called before init, leave the call sites unpatched for now. > > + * In the meantime they'll continue to call the temporary trampoline. > > + */ > > + if (!static_call_initialized) > > + goto done; > > + > > + list_for_each_entry(mod, &key->site_mods, list) { > > Since I'm expecting a lot of sites, I'm wondering if we should just do > this as an array, like I do with the ftrace call sites. > > But this can be an enhancement for later. Let's focus on getting this > working first. But it's not a static list. It can grow/shrink as modules are loaded/unload. > > > + if (!mod->sites) { > > + /* > > + * This can happen if the static call key is defined in > > + * a module which doesn't use it. > > + */ > > + continue; > > + } > > + > > + stop = __stop_static_call_sites; > > + > > +#ifdef CONFIG_MODULES > > + if (mod->mod) { > > BTW, "mod" is an unfortunate name. True. I'll change it to 'site_mod'. > > > + stop = mod->mod->static_call_sites + > > + mod->mod->num_static_call_sites; > > + } > > +#endif > > + > > + for (site = mod->sites; > > + site < stop && static_call_key(site) == key; site++) { > > + unsigned long addr = static_call_addr(site); > > + > > + if (!mod->mod && init_section_contains((void *)addr, 1)) > > + continue; > > + if (mod->mod && within_module_init(addr, mod->mod)) > > + continue; > > + > > > So what's the reason for skipping init calls? This is the runtime changing code (static_call_update). Presumably the init sections no longer exist and we shouldn't write to any (former) call sites there. That's probably a dangerous assumption though... If static_call_update() were called early, some init code might not get patched and then call into the wrong function. I'm thinking we should just disallow static call sites in init sections. I can't think of a good reason why they would be needed in init code. We can WARN when detecting them during boot / module init. -- Josh