Message-Id: <f8bcf5ce-8b8b-4555-a210-14e1974eac92@app.fastmail.com>
Date: Tue, 29 Jul 2025 11:34:57 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Kees Cook" <kees@...nel.org>
Cc: "Thomas Gleixner" <tglx@...utronix.de>, "Ingo Molnar" <mingo@...hat.com>,
 "Borislav Petkov" <bp@...en8.de>,
 "Dave Hansen" <dave.hansen@...ux.intel.com>, x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>, "Paolo Bonzini" <pbonzini@...hat.com>,
 "Mike Rapoport" <rppt@...nel.org>, "Ard Biesheuvel" <ardb@...nel.org>,
 "Vitaly Kuznetsov" <vkuznets@...hat.com>,
 "Henrique de Moraes Holschuh" <hmh@....eng.br>,
 "Hans de Goede" <hdegoede@...hat.com>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 "Rafael J . Wysocki" <rafael@...nel.org>, "Len Brown" <lenb@...nel.org>,
 "Masami Hiramatsu" <mhiramat@...nel.org>,
 "Michal Wilczynski" <michal.wilczynski@...el.com>,
 "Juergen Gross" <jgross@...e.com>,
 "Andy Shevchenko" <andriy.shevchenko@...ux.intel.com>,
 "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
 "Roger Pau Monne" <roger.pau@...rix.com>,
 "David Woodhouse" <dwmw@...zon.co.uk>,
 "Usama Arif" <usama.arif@...edance.com>,
 "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
 "Thomas Huth" <thuth@...hat.com>, "Brian Gerst" <brgerst@...il.com>,
 kvm@...r.kernel.org, ibm-acpi-devel@...ts.sourceforge.net,
 platform-driver-x86@...r.kernel.org, linux-acpi@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, linux-efi@...r.kernel.org,
 linux-mm@...ck.org, "Will Deacon" <will@...nel.org>,
 "Catalin Marinas" <catalin.marinas@....com>,
 "Jonathan Cameron" <Jonathan.Cameron@...wei.com>,
 "Gavin Shan" <gshan@...hat.com>,
 "Russell King" <rmk+kernel@...linux.org.uk>,
 "James Morse" <james.morse@....com>,
 "Oza Pawandeep" <quic_poza@...cinc.com>,
 "Anshuman Khandual" <anshuman.khandual@....com>,
 "Hans de Goede" <hansg@...nel.org>,
 "Kirill A. Shutemov" <kas@...nel.org>, "Marco Elver" <elver@...gle.com>,
 "Andrey Konovalov" <andreyknvl@...il.com>,
 "Andrey Ryabinin" <ryabinin.a.a@...il.com>,
 "Hou Wenlong" <houwenlong.hwl@...group.com>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "Masahiro Yamada" <masahiroy@...nel.org>,
 "Peter Zijlstra" <peterz@...radead.org>,
 "Luis Chamberlain" <mcgrof@...nel.org>,
 "Sami Tolvanen" <samitolvanen@...gle.com>,
 "Christophe Leroy" <christophe.leroy@...roup.eu>,
 "Nathan Chancellor" <nathan@...nel.org>,
 "Nicolas Schier" <nicolas.schier@...ux.dev>,
 "Gustavo A. R. Silva" <gustavoars@...nel.org>,
 "Andy Lutomirski" <luto@...nel.org>, "Baoquan He" <bhe@...hat.com>,
 "Alexander Graf" <graf@...zon.com>,
 "Changyuan Lyu" <changyuanl@...gle.com>,
 "Paul Moore" <paul@...l-moore.com>, "James Morris" <jmorris@...ei.org>,
 "Serge E. Hallyn" <serge@...lyn.com>,
 "Nick Desaulniers" <nick.desaulniers+lkml@...il.com>,
 "Bill Wendling" <morbo@...gle.com>,
 "Justin Stitt" <justinstitt@...gle.com>,
 "Jan Beulich" <jbeulich@...e.com>, "Boqun Feng" <boqun.feng@...il.com>,
 "Viresh Kumar" <viresh.kumar@...aro.org>,
 "Paul E. McKenney" <paulmck@...nel.org>,
 "Bibo Mao" <maobibo@...ngson.cn>, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, kasan-dev@...glegroups.com,
 linux-kbuild@...r.kernel.org, linux-hardening@...r.kernel.org,
 kexec@...ts.infradead.org, linux-security-module@...r.kernel.org,
 llvm@...ts.linux.dev
Subject: Re: [PATCH v4 2/4] x86: Handle KCOV __init vs inline mismatches

On Thu, Jul 24, 2025, at 07:50, Kees Cook wrote:
> GCC appears to have kind of fragile inlining heuristics, in the
> sense that it can change whether or not it inlines something based on
> optimizations. It looks like the kcov instrumentation being added (or in
> this case, removed) from a function changes the optimization results,
> and some functions marked "inline" are _not_ inlined. In that case,
> we end up with __init code calling a function not marked __init, and we
> get the build warnings I'm trying to eliminate in the coming patch that
> adds __no_sanitize_coverage to __init functions:
>
> WARNING: modpost: vmlinux: section mismatch in reference: xbc_exit+0x8 
> (section: .text.unlikely) -> _xbc_exit (section: .init.text)
> WARNING: modpost: vmlinux: section mismatch in reference: 
> real_mode_size_needed+0x15 (section: .text.unlikely) -> 
> real_mode_blob_end (section: .init.data)
> WARNING: modpost: vmlinux: section mismatch in reference: 
> __set_percpu_decrypted+0x16 (section: .text.unlikely) -> 
> early_set_memory_decrypted (section: .init.text)
> WARNING: modpost: vmlinux: section mismatch in reference: 
> memblock_alloc_from+0x26 (section: .text.unlikely) -> 
> memblock_alloc_try_nid (section: .init.text)
> WARNING: modpost: vmlinux: section mismatch in reference: 
> acpi_arch_set_root_pointer+0xc (section: .text.unlikely) -> x86_init 
> (section: .init.data)
> WARNING: modpost: vmlinux: section mismatch in reference: 
> acpi_arch_get_root_pointer+0x8 (section: .text.unlikely) -> x86_init 
> (section: .init.data)
> WARNING: modpost: vmlinux: section mismatch in reference: 
> efi_config_table_is_usable+0x16 (section: .text.unlikely) -> 
> xen_efi_config_table_is_usable (section: .init.text)
>
> This problem is somewhat fragile (though using either __always_inline
> or __init will deterministically solve it), but we've tripped over
> this before with GCC and the solution has usually been to just use
> __always_inline and move on.
>
> For x86 this means forcing several functions to be inline with
> __always_inline.
>
> Signed-off-by: Kees Cook <kees@...nel.org>

Acked-by: Arnd Bergmann <arnd@...db.de>

In my randconfig tests, I got these ones as well:

WARNING: modpost: vmlinux: section mismatch in reference: early_page_ext_enabled+0x14 (section: .text.unlikely) -> early_
page_ext (section: .init.data)
x86_64-linux-ld: lm75.c:(.text+0xd25): undefined reference to `i3c_device_do_priv_xfers'

And one more with a private patch of mine.

These are the fixups that make it build for arm/arm64/x86
randconfigs for me, so you could fold them as well in
as well. I have already sent the i3c patch for upstream
but not the page_ext.h patch.

--- a/include/linux/page_ext.h
+++ b/include/linux/page_ext.h
@@ -57,7 +57,7 @@ extern bool early_page_ext;
 extern unsigned long page_ext_size;
 extern void pgdat_page_ext_init(struct pglist_data *pgdat);
 
-static inline bool early_page_ext_enabled(void)
+static __always_inline bool early_page_ext_enabled(void)
 {
        return early_page_ext;
 }
@@ -189,7 +189,7 @@ static inline struct page_ext *page_ext_iter_get(const struct page_ext_iter *ite
 #else /* !CONFIG_PAGE_EXTENSION */
 struct page_ext;
 
-static inline bool early_page_ext_enabled(void)
+static __always_inline bool early_page_ext_enabled(void)
 {
        return false;
 }
--- a/include/linux/i3c/device.h
+++ b/include/linux/i3c/device.h
@@ -245,7 +245,7 @@ void i3c_driver_unregister(struct i3c_driver *drv);
  *
  * Return: 0 if both registrations succeeds, a negative error code otherwise.
  */
-static inline int i3c_i2c_driver_register(struct i3c_driver *i3cdrv,
+static __always_inline int i3c_i2c_driver_register(struct i3c_driver *i3cdrv,
                                          struct i2c_driver *i2cdrv)
 {
        int ret;
@@ -270,7 +270,7 @@ static inline int i3c_i2c_driver_register(struct i3c_driver *i3cdrv,
  * Note that when CONFIG_I3C is not enabled, this function only unregisters the
  * @i2cdrv.
  */
-static inline void i3c_i2c_driver_unregister(struct i3c_driver *i3cdrv,
+static __always_inline void i3c_i2c_driver_unregister(struct i3c_driver *i3cdrv,
                                             struct i2c_driver *i2cdrv)
 {
        if (IS_ENABLED(CONFIG_I3C))

As I understand, the underlying problem is less gcc inlining
being fragile, but more that gcc does not inline functions
when they have different __no_sanitize_coverage attributes.

      Arnd

Powered by blists - more mailing lists