From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5D823C457A for ; Tue, 28 Jul 2026 18:52:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.200 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785264766; cv=none; b=GbFlWPVAEN7WEM9llbyuu6cgABXlyqdgMyb/0hjvOf5+KmtvFfEJn9D7wovWqUMail2f7SSGwTWr+cSOn3PjB28JZvx3LXP4frGpieaafKq+J7YBvFRI50L+g2p3i2q+ddU8kypgyk6oH0jDnboyf1D7VaHOEZ9NHamWwEWPXXY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785264766; c=relaxed/simple; bh=l2Es26jUxus/pyPxMghMUP1yIXuAWO7tK+rKBlkL2CE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=sSqodSjSB3S9TGZ+M+FmP2AK8N7v+vtYn9ZahzXOZ40IztaEUM7axsTjxyI24aueSdiK0mzwgOSGkFeoQiZgsjR/IbV+XpdCC9iIW9khomKDbyVrKSsP3ruhqle6oY8U9hpGGCJY9rfG8j/NrvHCD0XA/KHXSmMzhAdXFws11MM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=nUxq8Dhq; arc=none smtp.client-ip=209.85.214.200 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="nUxq8Dhq" Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2cceabd70f5so5044845ad.1 for ; Tue, 28 Jul 2026 11:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1785264762; x=1785869562; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=EURzVSWhRSOOgqb3RqZuisJ1IP2IjYHX1FhuQfx4G4s=; b=nUxq8DhqIxUAbFbipxgS79prGPpoMB7vH9pEPhKrlJv0iGol0LVoyR/7SbZWKE2qEq U2gpHp0APz8HkhJEpOl6P1gDmcDoUtq/6gJFQKQrJWLBn2wXkcS1tnzWrXp1pBuZ0GOi xV97Z6wGae3ZHgMmFRErLmFpo2h5PxLdUWY09qwPam2C3OTWWQv3Y6b0UyN4kPL4mWXp wkRKwV8EqTGg8CUEFGZN8B3bcOdfx4CQsBJanI4+5sANPCCvGTqlgDQzlqU7eK9FW0E/ a/AQOdGnEshSlHR932LUj4GSQsg3wUVrsJC8MttLEf/xsp61wM6A02JCmu3EfKpjMIIa xxHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785264762; x=1785869562; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=EURzVSWhRSOOgqb3RqZuisJ1IP2IjYHX1FhuQfx4G4s=; b=BJodQafbn/bQF8wWp2QLSQxEpz/RrDhcrS60BMksfvtIwQHAq6CF5KAu84pSnEVBOI cumRP40ZTm2Z8Rneb8jQ+DddIxJH/FkdJ29GVKVztlEauUFmIEDAHSuk/NqTX8WuzQQ0 Hxnh4lQ1vYBfBi4PmdYG/HRHZGPHRA07T3gqvacu86iXVfEJFhuTaXz4hIEH05rX3btU LEWoA5yrDUvQb/cD9yWjMceZMDJRGZSNfMm3nvXwCmnoZHx4gaZYn8IvTpcYbqTfc5Av tHguoWTsri/oS1Pnc0B3+mr0Dh5hpJyjn4Vd8WhoXwY537N59kQLm8oZim5nQL5wuqyb xc0w== X-Forwarded-Encrypted: i=1; AHgh+Rq2LSdqv8JlW1IOiB7K/ptu50Dn+Lxth5GNX1tpNf01eaTFGuzfUO5t1GRNMBqHEjCNbvH7SzI=@vger.kernel.org X-Gm-Message-State: AOJu0YxLfrY2CxTzeRXnD8UCXU263GVObDtHPMvpVcgd2FZL2yCIVa5p 0ACgVvTty+8bfrJwPZBBiw2z1KCfy/5FpaJBrjlRJytL7NIH/nf2M3BMcKpic+W8QP6VqjJkNxe vY4xWow== X-Received: from plec7.prod.google.com ([2002:a17:902:f307:b0:2c7:f19d:bb15]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:f710:b0:2ca:a03a:29b2 with SMTP id d9443c01a7336-2d015c9c0c4mr48784125ad.8.1785264762144; Tue, 28 Jul 2026 11:52:42 -0700 (PDT) Date: Tue, 28 Jul 2026 11:52:41 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260622-vmscape-bhb-v12-0-76cbda0ae3e5@linux.intel.com> <20260622-vmscape-bhb-v12-7-76cbda0ae3e5@linux.intel.com> Message-ID: Subject: Re: [PATCH v12 07/12] static_call: Define EXPORT_STATIC_CALL_FOR_MODULES() From: Sean Christopherson To: Pawan Gupta Cc: x86@kernel.org, Jon Kohler , Nikolay Borisov , "H. Peter Anvin" , Josh Poimboeuf , David Kaplan , Borislav Petkov , Dave Hansen , Peter Zijlstra , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , KP Singh , Jiri Olsa , "David S. Miller" , David Laight , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , David Ahern , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , John Fastabend , Stanislav Fomichev , Hao Luo , Paolo Bonzini , Jonathan Corbet , Jason Baron , Alice Ryhl , Steven Rostedt , Ard Biesheuvel , Shuah Khan , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick , Tao Zhang , bpf@vger.kernel.org, netdev@vger.kernel.org, linux-doc@vger.kernel.org Content-Type: text/plain; charset="us-ascii" On Wed, Jun 24, 2026, Sean Christopherson wrote: > On Tue, Jun 23, 2026, Pawan Gupta wrote: > > There is EXPORT_STATIC_CALL_TRAMP() that hides the static key from all > > modules. But there is no equivalent of EXPORT_SYMBOL_FOR_MODULES() to > > restrict symbol visibility to only certain modules. > > > > Add EXPORT_STATIC_CALL_FOR_MODULES(name, mods) that wraps both the key and > > the trampoline with EXPORT_SYMBOL_FOR_MODULES(), allowing only a limited > > set of modules to see and update the static key. > > > > The immediate user is KVM, in the following commit. > > > > checkpatch reported below warnings with this change that I believe don't > > apply in this case: > > > > include/linux/static_call.h:219: WARNING: Non-declarative macros with multiple statements should be enclosed in a do - while loop > > include/linux/static_call.h:220: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable > > > > Suggested-by: Peter Zijlstra > > Signed-off-by: Pawan Gupta > > --- > > include/linux/static_call.h | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/include/linux/static_call.h b/include/linux/static_call.h > > index 78a77a4ae0ea..b610afd1ed55 100644 > > --- a/include/linux/static_call.h > > +++ b/include/linux/static_call.h > > @@ -216,6 +216,9 @@ extern long __static_call_return0(void); > > #define EXPORT_STATIC_CALL_GPL(name) \ > > EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)); \ > > EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name)) > > +#define EXPORT_STATIC_CALL_FOR_MODULES(name, mods) \ > > + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_KEY(name), mods); \ > > + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_TRAMP(name), mods) > > > > /* Leave the key unexported, so modules can't change static call targets: */ > > #define EXPORT_STATIC_CALL_TRAMP(name) \ > > @@ -276,6 +279,9 @@ extern long __static_call_return0(void); > > #define EXPORT_STATIC_CALL_GPL(name) \ > > EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)); \ > > EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(name)) > > +#define EXPORT_STATIC_CALL_FOR_MODULES(name, mods) \ > > + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_KEY(name), mods); \ > > + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_TRAMP(name), mods) > > > > /* Leave the key unexported, so modules can't change static call targets: */ > > #define EXPORT_STATIC_CALL_TRAMP(name) \ > > @@ -346,6 +352,8 @@ static inline int static_call_text_reserved(void *start, void *end) > > > > #define EXPORT_STATIC_CALL(name) EXPORT_SYMBOL(STATIC_CALL_KEY(name)) > > #define EXPORT_STATIC_CALL_GPL(name) EXPORT_SYMBOL_GPL(STATIC_CALL_KEY(name)) > > +#define EXPORT_STATIC_CALL_FOR_MODULES(name, mods) \ > > + EXPORT_SYMBOL_FOR_MODULES(STATIC_CALL_KEY(name), mods) > > > > #endif /* CONFIG_HAVE_STATIC_CALL */ > > Drat, I forgot about this. Exporting static call trampolines for KVM came up in > another conversation[*]. I had already put together patches to effectively default > to exporting only the trampoline, and also to deduplicate this code so that the > CONFIG_HAVE_STATIC_CALL_INLINE=y / CONFIG_HAVE_STATIC_CALL=y / CONFIG_HAVE_STATIC_CALL=n > implementations don't need to copy+paste the same lines of code. > > The attached patches touch a lot more code, and will conflict mightily with KVM > changes I want to land in 7.3 (more use of a static_call in KVM). But if we get > them applied (to tip tree) shortly after 7.2-rc1 and provide a topic branch/tag, > then there shouldn't be too much juggling needed? > > If we want to go with the more aggressive cleanup, I'll formally post the patches. *sigh* So the patches build, but they aren't fully functional. If kvm.ko is built as a module, trying to load a vendor module will fail due to the trampoline => key table only tracking built-in symbols. Given that all of this is KVM, and that it's far easier to export the static calls if and only if there are vendor modules, and only for those vendor modules, I'm going to drop the aggressive cleanup and abandon converting KVM's exports to only export trampolines, at least until someone else works up the motivation to add support for modules. > [*] https://lore.kernel.org/all/ahhoDGUz39KSGZ6o@google.com