[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aIiGHmw8IJb9vsM5@kernel.org>
Date: Tue, 29 Jul 2025 11:28:14 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Kees Cook <kees@...nel.org>
Cc: Arnd Bergmann <arnd@...db.de>, 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>,
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 (Oracle)" <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 (Intel)" <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 Wed, Jul 23, 2025 at 10:50:26PM -0700, 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>
For memblock bit:
Acked-by: Mike Rapoport (Microsoft) <rppt@...nel.org>
--
Sincerely yours,
Mike.
Powered by blists - more mailing lists