Messages in this thread | | | From | Daniel Axtens <> | Subject | ARCH_WANTS_NO_INSTR (Re: [GIT PULL] Clang feature updates for v5.14-rc1) | Date | Wed, 6 Oct 2021 00:10:15 +1100 |
| |
Hi,
Apologies, I can't find the original email for this:
> Kconfig: Introduce ARCH_WANTS_NO_INSTR and CC_HAS_NO_PROFILE_FN_ATTR
which is now commit 51c2ee6d121c ("Kconfig: Introduce ARCH_WANTS_NO_INSTR and CC_HAS_NO_PROFILE_FN_ATTR"). It doesn't seem to show up on Google, this was the best I could find.
Anyway, the commit message reads:
Kconfig: Introduce ARCH_WANTS_NO_INSTR and CC_HAS_NO_PROFILE_FN_ATTR
We don't want compiler instrumentation to touch noinstr functions, which are annotated with the no_profile_instrument_function function attribute. Add a Kconfig test for this and make GCOV depend on it, and in the future, PGO.
If an architecture is using noinstr, it should denote that via this Kconfig value. That makes Kconfigs that depend on noinstr able to express dependencies in an architecturally agnostic way.
However, things in generic code (such as rcu_nmi_enter) are tagged with `noinstr`, so I'm worried that this commit subtly breaks things like KASAN on platforms that haven't opted in yet. (I stumbled across this while developing KASAN on ppc64, but at least riscv and ppc32 have KASAN but not ARCH_WANTS_NO_INSTR already.)
As I said, I haven't been able to find the original thread - is there any reason this shouldn't be always on? Why would an arch not opt in? What's the motivation for ignoring the noinstr markings?
Should generic KASAN/KCSAN/anything else marked in noinstr also have markings requring ARCH_WANTS_NO_INSTR? AFAICT they should, right?
Kind regards, Daniel
| |