stackleak: Support Clang stack depth tracking

In preparation for adding Clang sanitizer coverage stack depth tracking that can support stack depth callbacks:

- Add the new top-level CONFIG_KSTACK_ERASE option which will be implemented either with the stackleak GCC plugin, or with the Clang stack depth callback support.
- Rename CONFIG_GCC_PLUGIN_STACKLEAK as needed to CONFIG_KSTACK_ERASE, but keep it for anything specific to the GCC plugin itself.
- Rename all exposed "STACKLEAK" names and files to "KSTACK_ERASE" (named for what it does rather than what it protects against), but leave as many of the internals alone as possible to avoid even more churn.

While here, also split "prev_lowest_stack" into CONFIG_KSTACK_ERASE_METRICS, since that's the only place it is referenced from.

Suggested-by Ingo Molnar <[email protected]>

Signed-off-by Kees Cook <[email protected]>

---
Cc: Arnd Bergmann <[email protected]>
Cc: <[email protected]>
Cc: "Gustavo A. R. Silva" <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>

---
 arch/Kconfig                                  |  4 +--
 arch/arm/Kconfig                              |  2 +-
 arch/arm64/Kconfig                            |  2 +-
 arch/riscv/Kconfig                            |  2 +-
 arch/s390/Kconfig                             |  2 +-
 arch/x86/Kconfig                              |  2 +-
 security/Kconfig.hardening                    | 36 ++++++++++---------
 arch/arm/boot/compressed/Makefile             |  2 +-
 arch/arm64/kernel/pi/Makefile                 |  2 +-
 arch/arm64/kvm/hyp/nvhe/Makefile              |  2 +-
 arch/riscv/kernel/pi/Makefile                 |  2 +-
 arch/riscv/purgatory/Makefile                 |  2 +-
 arch/x86/purgatory/Makefile                   |  2 +-

Quoted 31 lines · Kees Cook

In preparation for adding Clang sanitizer coverage stack depth tracking that can support stack depth callbacks:

- Add the new top-level CONFIG_KSTACK_ERASE option which will be implemented either with the stackleak GCC plugin, or with the Clang stack depth callback support.
- Rename CONFIG_GCC_PLUGIN_STACKLEAK as needed to CONFIG_KSTACK_ERASE, but keep it for anything specific to the GCC plugin itself.
- Rename all exposed "STACKLEAK" names and files to "KSTACK_ERASE" (named for what it does rather than what it protects against), but leave as many of the internals alone as possible to avoid even more churn.

While here, also split "prev_lowest_stack" into CONFIG_KSTACK_ERASE_METRICS, since that's the only place it is referenced from.

Suggested-by Ingo Molnar <[email protected]>

Signed-off-by Kees Cook <[email protected]>

---
Cc: Arnd Bergmann <[email protected]>
Cc: <[email protected]>
Cc: "Gustavo A. R. Silva" <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>
Cc: <[email protected]>

Quoted 14 lines

---
 arch/Kconfig                                  |  4 +--
 arch/arm/Kconfig                              |  2 +-
 arch/arm64/Kconfig                            |  2 +-
 arch/riscv/Kconfig                            |  2 +-
 arch/s390/Kconfig                             |  2 +-
 arch/x86/Kconfig                              |  2 +-
 security/Kconfig.hardening                    | 36 ++++++++++---------
 arch/arm/boot/compressed/Makefile             |  2 +-
 arch/arm64/kernel/pi/Makefile                 |  2 +-
 arch/arm64/kvm/hyp/nvhe/Makefile              |  2 +-
 arch/riscv/kernel/pi/Makefile                 |  2 +-
 arch/riscv/purgatory/Makefile                 |  2 +-
 arch/x86/purgatory/Makefile                   |  2 +-

Did you miss arch/loongarch/Kconfig by accident?

$ git grep -Hrne ARCH_STACKLEAK
arch/loongarch/Kconfig:127:     select HAVE_ARCH_STACKLEAK

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For x86 this means forcing several functions to be inline with __always_inline.

Signed-off-by Kees Cook <[email protected]>

Hi Kees,

Quoted 8 lines · Kees Cook

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For x86 this means forcing several functions to be inline with __always_inline.

Signed-off-by Kees Cook <[email protected]>

...

Quoted 8 lines

include/linux/memblock.h +0 -0

index bb19a2534224..b96746376e17 100644
@@ -463,7 +463,7 @@ static inline void *memblock_alloc_raw(phys_addr_t size,
 					  NUMA_NO_NODE);
 }
 

include/linux/memblock.h static inline void *memblock_alloc_raw(phys_addr_t size, · line 468

Quoted 4 lines

include/linux/memblock.h +1 -1

-static inline void *memblock_alloc_from(phys_addr_t size,
+static __always_inline void *memblock_alloc_from(phys_addr_t size,
 						phys_addr_t align,
 						phys_addr_t min_addr)

I'm curious why from all memblock_alloc* wrappers this is the only one that needs to be __always_inline?

Quoted 22 lines · Mike Rapoport

Hi Kees,

Quoted 8 lines · Kees Cook

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For x86 this means forcing several functions to be inline with __always_inline.

Signed-off-by Kees Cook <[email protected]>

...

Quoted 8 lines

include/linux/memblock.h +0 -0

index bb19a2534224..b96746376e17 100644
@@ -463,7 +463,7 @@ static inline void *memblock_alloc_raw(phys_addr_t size,
                                      NUMA_NO_NODE);
 }
 

Quoted 7 lines

include/linux/memblock.h static inline void *memblock_alloc_raw(phys_addr_t size, · line 468

Quoted 4 lines

include/linux/memblock.h +1 -1

-static inline void *memblock_alloc_from(phys_addr_t size,
+static __always_inline void *memblock_alloc_from(phys_addr_t size,
                                            phys_addr_t align,
                                            phys_addr_t min_addr)

I'm curious why from all memblock_alloc* wrappers this is the only one that needs to be __always_inline?

Thread-merge[1], adding Will Deacon, who was kind of asking the same question.

Based on what I can tell, GCC has kind of fragile inlining logic, 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.

So, to Will's comment, yes, the problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it). We've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on.

Quoted 32 lines · Kees Cook

Quoted 20 lines · Mike Rapoport

Quoted 8 lines · Kees Cook

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For x86 this means forcing several functions to be inline with __always_inline.

Signed-off-by Kees Cook <[email protected]>

...

Quoted 8 lines

include/linux/memblock.h +0 -0

index bb19a2534224..b96746376e17 100644
@@ -463,7 +463,7 @@ static inline void *memblock_alloc_raw(phys_addr_t size,
                                      NUMA_NO_NODE);
 }
 

Quoted 7 lines

include/linux/memblock.h static inline void *memblock_alloc_raw(phys_addr_t size, · line 468

Quoted 4 lines

include/linux/memblock.h +1 -1

-static inline void *memblock_alloc_from(phys_addr_t size,
+static __always_inline void *memblock_alloc_from(phys_addr_t size,
                                            phys_addr_t align,
                                            phys_addr_t min_addr)

I'm curious why from all memblock_alloc* wrappers this is the only one that needs to be __always_inline?

Thread-merge[1], adding Will Deacon, who was kind of asking the same question.

Quoted 7 lines

Based on what I can tell, GCC has kind of fragile inlining logic, 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.

Quoted 5 lines

So, to Will's comment, yes, the problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it). We've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on.

Given that 'inline' is already a macro in the kernel, could we just add __attribute__((__always_inline__)) to it when KCOV is enabled?

Quoted 33 lines · Ard Biesheuvel

Quoted 32 lines · Kees Cook

Quoted 20 lines · Mike Rapoport

Quoted 8 lines · Kees Cook

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For x86 this means forcing several functions to be inline with __always_inline.

Signed-off-by Kees Cook <[email protected]>

...

Quoted 8 lines

include/linux/memblock.h +0 -0

index bb19a2534224..b96746376e17 100644
@@ -463,7 +463,7 @@ static inline void *memblock_alloc_raw(phys_addr_t size,
                                      NUMA_NO_NODE);
 }
 

Quoted 7 lines

include/linux/memblock.h static inline void *memblock_alloc_raw(phys_addr_t size, · line 468

Quoted 4 lines

include/linux/memblock.h +1 -1

-static inline void *memblock_alloc_from(phys_addr_t size,
+static __always_inline void *memblock_alloc_from(phys_addr_t size,
                                            phys_addr_t align,
                                            phys_addr_t min_addr)

I'm curious why from all memblock_alloc* wrappers this is the only one that needs to be __always_inline?

Thread-merge[1], adding Will Deacon, who was kind of asking the same question.

Quoted 7 lines

Quoted 7 lines

Based on what I can tell, GCC has kind of fragile inlining logic, 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.

Got it, thanks for the explanation!

Quoted 6 lines

Quoted 5 lines

So, to Will's comment, yes, the problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it). We've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on.

Quoted 2 lines

Given that 'inline' is already a macro in the kernel, could we just add __attribute__((__always_inline__)) to it when KCOV is enabled?

That sounds like a more robust approach and, by the sounds of it, we could predicate it on GCC too. That would also provide a neat place for a comment describing the problem.

Kees, would that work for you?

Quoted 50 lines · Will Deacon

Quoted 33 lines · Ard Biesheuvel

Quoted 32 lines · Kees Cook

Quoted 20 lines · Mike Rapoport

Quoted 8 lines · Kees Cook

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For x86 this means forcing several functions to be inline with __always_inline.

Signed-off-by Kees Cook <[email protected]>

...

Quoted 8 lines

include/linux/memblock.h +0 -0

index bb19a2534224..b96746376e17 100644
@@ -463,7 +463,7 @@ static inline void *memblock_alloc_raw(phys_addr_t size,
                                      NUMA_NO_NODE);
 }
 

Quoted 7 lines

include/linux/memblock.h static inline void *memblock_alloc_raw(phys_addr_t size, · line 468

Quoted 4 lines

include/linux/memblock.h +1 -1

-static inline void *memblock_alloc_from(phys_addr_t size,
+static __always_inline void *memblock_alloc_from(phys_addr_t size,
                                            phys_addr_t align,
                                            phys_addr_t min_addr)

I'm curious why from all memblock_alloc* wrappers this is the only one that needs to be __always_inline?

Thread-merge[1], adding Will Deacon, who was kind of asking the same question.

Quoted 7 lines

Quoted 7 lines

Based on what I can tell, GCC has kind of fragile inlining logic, 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.

Got it, thanks for the explanation!

Quoted 6 lines

Quoted 5 lines

So, to Will's comment, yes, the problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it). We've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on.

Quoted 8 lines

Quoted 2 lines

Given that 'inline' is already a macro in the kernel, could we just add __attribute__((__always_inline__)) to it when KCOV is enabled?

That sounds like a more robust approach and, by the sounds of it, we could predicate it on GCC too. That would also provide a neat place for a comment describing the problem.

Kees, would that work for you?

That seems like an extremely large hammer for this problem, IMO. It feels like it could cause new strange corner cases. I'd much prefer the small fixes I've currently got since it keeps it focused. KCOV is already enabled for "allmodconfig", so any new instances would be found very quickly, etc. (And GCC's fragility in this regard has already been exposed to these cases -- it's just that I changed one of the combinations of __init vs inline vs instrumentation.

I could give it a try, if you really prefer the big hammer approach...

Quoted 68 lines · Kees Cook

Quoted 50 lines · Will Deacon

Quoted 33 lines · Ard Biesheuvel

Quoted 32 lines · Kees Cook

Quoted 20 lines · Mike Rapoport

Quoted 8 lines · Kees Cook

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For x86 this means forcing several functions to be inline with __always_inline.

Signed-off-by Kees Cook <[email protected]>

...

Quoted 8 lines

include/linux/memblock.h +0 -0

index bb19a2534224..b96746376e17 100644
@@ -463,7 +463,7 @@ static inline void *memblock_alloc_raw(phys_addr_t size,
                                      NUMA_NO_NODE);
 }
 

Quoted 7 lines

include/linux/memblock.h static inline void *memblock_alloc_raw(phys_addr_t size, · line 468

Quoted 4 lines

include/linux/memblock.h +1 -1

-static inline void *memblock_alloc_from(phys_addr_t size,
+static __always_inline void *memblock_alloc_from(phys_addr_t size,
                                            phys_addr_t align,
                                            phys_addr_t min_addr)

I'm curious why from all memblock_alloc* wrappers this is the only one that needs to be __always_inline?

Thread-merge[1], adding Will Deacon, who was kind of asking the same question.

Quoted 7 lines

Quoted 7 lines

Based on what I can tell, GCC has kind of fragile inlining logic, 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.

Got it, thanks for the explanation!

Quoted 6 lines

Quoted 5 lines

So, to Will's comment, yes, the problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it). We've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on.

Quoted 8 lines

Quoted 2 lines

Given that 'inline' is already a macro in the kernel, could we just add __attribute__((__always_inline__)) to it when KCOV is enabled?

That sounds like a more robust approach and, by the sounds of it, we could predicate it on GCC too. That would also provide a neat place for a comment describing the problem.

Kees, would that work for you?

That seems like an extremely large hammer for this problem, IMO. It feels like it could cause new strange corner cases. I'd much prefer the small fixes I've currently got since it keeps it focused. KCOV is already enabled for "allmodconfig", so any new instances would be found very quickly, etc. (And GCC's fragility in this regard has already been exposed to these cases -- it's just that I changed one of the combinations of __init vs inline vs instrumentation.

Quoted 1 line

I could give it a try, if you really prefer the big hammer approach...

I gave it a try -- it fails spectacularly. ;) Let's stick to my small fixes instead?

Quoted 70 lines · Kees Cook

Quoted 68 lines · Kees Cook

Quoted 50 lines · Will Deacon

Quoted 33 lines · Ard Biesheuvel

Quoted 32 lines · Kees Cook

Quoted 20 lines · Mike Rapoport

Quoted 8 lines · Kees Cook

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For x86 this means forcing several functions to be inline with __always_inline.

Signed-off-by Kees Cook <[email protected]>

...

Quoted 8 lines

include/linux/memblock.h +0 -0

index bb19a2534224..b96746376e17 100644
@@ -463,7 +463,7 @@ static inline void *memblock_alloc_raw(phys_addr_t size,
                                      NUMA_NO_NODE);
 }
 

Quoted 7 lines

include/linux/memblock.h static inline void *memblock_alloc_raw(phys_addr_t size, · line 468

Quoted 4 lines

include/linux/memblock.h +1 -1

-static inline void *memblock_alloc_from(phys_addr_t size,
+static __always_inline void *memblock_alloc_from(phys_addr_t size,
                                            phys_addr_t align,
                                            phys_addr_t min_addr)

I'm curious why from all memblock_alloc* wrappers this is the only one that needs to be __always_inline?

Thread-merge[1], adding Will Deacon, who was kind of asking the same question.

Quoted 7 lines

Quoted 7 lines

Based on what I can tell, GCC has kind of fragile inlining logic, 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.

Got it, thanks for the explanation!

Quoted 6 lines

Quoted 5 lines

So, to Will's comment, yes, the problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it). We've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on.

Quoted 8 lines

Quoted 2 lines

Given that 'inline' is already a macro in the kernel, could we just add __attribute__((__always_inline__)) to it when KCOV is enabled?

That sounds like a more robust approach and, by the sounds of it, we could predicate it on GCC too. That would also provide a neat place for a comment describing the problem.

Kees, would that work for you?

That seems like an extremely large hammer for this problem, IMO. It feels like it could cause new strange corner cases. I'd much prefer the small fixes I've currently got since it keeps it focused. KCOV is already enabled for "allmodconfig", so any new instances would be found very quickly, etc. (And GCC's fragility in this regard has already been exposed to these cases -- it's just that I changed one of the combinations of __init vs inline vs instrumentation.

Quoted 5 lines

Quoted 1 line

I could give it a try, if you really prefer the big hammer approach...

I gave it a try -- it fails spectacularly. ;) Let's stick to my small fixes instead?

Fair enough :-)

Quoted 22 lines · Mike Rapoport

Hi Kees,

Quoted 8 lines · Kees Cook

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For x86 this means forcing several functions to be inline with __always_inline.

Signed-off-by Kees Cook <[email protected]>

...

Quoted 8 lines

include/linux/memblock.h +0 -0

index bb19a2534224..b96746376e17 100644
@@ -463,7 +463,7 @@ static inline void *memblock_alloc_raw(phys_addr_t size,
 					  NUMA_NO_NODE);
 }
 

Quoted 7 lines

include/linux/memblock.h static inline void *memblock_alloc_raw(phys_addr_t size, · line 468

Quoted 4 lines

include/linux/memblock.h +1 -1

-static inline void *memblock_alloc_from(phys_addr_t size,
+static __always_inline void *memblock_alloc_from(phys_addr_t size,
 						phys_addr_t align,
 						phys_addr_t min_addr)

I'm curious why from all memblock_alloc* wrappers this is the only one that needs to be __always_inline?

Thread-merge[1], adding Will Deacon, who was kind of asking the same question.

Based on what I can tell, GCC has kind of fragile inlining logic, 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.

So, to Will's comment, yes, the problem is somewhat fragile (though using either __always_inline or __init will deterministically solve it). We've tripped over this before with GCC and the solution has usually been to just use __always_inline and move on.

For memblock_alloc*, it appears to be that the heuristic GCC uses resulted in only memblock_alloc_from() being a problem in this case. I can certainly mark them all as __always_inline if that is preferred.

Signature · 1 line

Kees Cook

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For arm this exposed several places where __init annotations were missing but ended up being "accidentally correct". Fix these cases and force several functions to be inline with __always_inline.

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For arm this exposed several places where __init annotations were missing but ended up being "accidentally correct". Fix these cases and force several functions to be inline with __always_inline.

Acked-by Nishanth Menon <[email protected]>

Signed-off-by Kees Cook <[email protected]>

---
Cc: Russell King <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Nishanth Menon <[email protected]>
Cc: Santosh Shilimkar <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Allison Randal <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: <[email protected]>

---
 include/linux/mfd/dbx500-prcmu.h  | 2 +-

 arch/arm/mm/cache-feroceon-l2.c   | 2 +-
 arch/arm/mm/cache-tauros2.c       | 2 +-
 drivers/clocksource/timer-orion.c | 2 +-
 drivers/soc/ti/pm33xx.c           | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

include/linux/mfd/dbx500-prcmu.h +1 -1

index 98567623c9df..828362b7860c 100644
@@ -213,7 +213,7 @@ struct prcmu_fw_version {
 
 #if defined(CONFIG_UX500_SOC_DB8500)
 
-static inline void prcmu_early_init(void)
+static inline void __init prcmu_early_init(void)
 {
 	db8500_prcmu_early_init();
 }

arch/arm/mm/cache-feroceon-l2.c +1 -1

index 25dbd84a1aaf..2bfefb252ffd 100644
@@ -295,7 +295,7 @@ static inline u32 read_extra_features(void)
 	return u;
 }
 
-static inline void write_extra_features(u32 u)
+static inline void __init write_extra_features(u32 u)
 {
 	__asm__("mcr p15, 1, %0, c15, c1, 0" : : "r" (u));
 }

arch/arm/mm/cache-tauros2.c +1 -1

index b1e1aba602f7..bfe166ccace0 100644
@@ -177,7 +177,7 @@ static inline void __init write_actlr(u32 actlr)
 	__asm__("mcr p15, 0, %0, c1, c0, 1\n" : : "r" (actlr));
 }
 
-static void enable_extra_feature(unsigned int features)
+static void __init enable_extra_feature(unsigned int features)
 {
 	u32 u;
 

drivers/clocksource/timer-orion.c +1 -1

index 49e86cb70a7a..61f1e27fc41e 100644
@@ -43,7 +43,7 @@ static struct delay_timer orion_delay_timer = {
 	.read_current_timer = orion_read_timer,
 };
 
-static void orion_delay_timer_init(unsigned long rate)
+static void __init orion_delay_timer_init(unsigned long rate)
 {
 	orion_delay_timer.freq = rate;
 	register_current_timer_delay(&orion_delay_timer);

drivers/soc/ti/pm33xx.c +1 -1

index dfdff186c805..dc52a2197d24 100644
@@ -145,7 +145,7 @@ static int am33xx_do_sram_idle(u32 wfi_flags)
 	return pm_ops->cpu_suspend(am33xx_do_wfi_sram, wfi_flags);
 }
 
-static int __init am43xx_map_gic(void)
+static int am43xx_map_gic(void)
 {
 	gic_dist_base = ioremap(AM43XX_GIC_DIST_BASE, SZ_4K);
 

Signature · 1 line

2.34.1

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For arm64 this requires forcing one function to be inline with __always_inline.

Quoted 1 line

WARNING: modpost: vmlinux: section mismatch in reference:

When KCOV is enabled all functions get instrumented, unless the __no_sanitize_coverage attribute is used. To prepare for __no_sanitize_coverage being applied to __init functions, we have to handle differences in how GCC's inline optimizations get resolved. For mips this requires adding the __init annotation on init_mips_clocksource().

Signed-off-by Kees Cook <[email protected]>

---
Cc: Thomas Bogendoerfer <[email protected]>
Cc: <[email protected]>

---
 arch/mips/include/asm/time.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/mips/include/asm/time.h +1 -2

index e855a3611d92..5e7193b759f3 100644
@@ -55,7 +55,7 @@ static inline int mips_clockevent_init(void)
  */
 extern int init_r4k_clocksource(void);
 
-static inline int init_mips_clocksource(void)
+static inline __init int init_mips_clocksource(void)
 {
 #ifdef CONFIG_CSRC_R4K
        return init_r4k_clocksource();
--

2.34.1