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 <k...@kernel.org>
Acked-by: Arnd Bergmann <a...@arndb.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
