Balbir Singh <bsingharora@xxxxxxxxx> writes: > On Sat, Mar 20, 2021 at 01:40:53AM +1100, Daniel Axtens wrote: >> For annoying architectural reasons, it's very difficult to support inline >> instrumentation on powerpc64. > > I think we can expand here and talk about how in hash mode, the vmalloc > address space is in a region of memory different than where kernel virtual > addresses are mapped. Did I recollect the reason correctly? I think that's _a_ reason, but for radix mode (which is all I support at the moment), the reason is a bit simpler. We call into generic code like the DT parser and printk when we have translations off. The shadow region lives at c00e.... which is not part of the linear mapping, so if you try to access the shadow while in real mode you will access unmapped memory and (at least on PowerNV) take a machine check. >> >> Add a Kconfig flag to allow an arch to disable inline. (It's a bit >> annoying to be 'backwards', but I'm not aware of any way to have >> an arch force a symbol to be 'n', rather than 'y'.) >> >> We also disable stack instrumentation in this case as it does things that >> are functionally equivalent to inline instrumentation, namely adding >> code that touches the shadow directly without going through a C helper. >> >> Signed-off-by: Daniel Axtens <dja@xxxxxxxxxx> >> --- >> lib/Kconfig.kasan | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan >> index cffc2ebbf185..7e237dbb6df3 100644 >> --- a/lib/Kconfig.kasan >> +++ b/lib/Kconfig.kasan >> @@ -12,6 +12,9 @@ config HAVE_ARCH_KASAN_HW_TAGS >> config HAVE_ARCH_KASAN_VMALLOC >> bool >> >> +config ARCH_DISABLE_KASAN_INLINE >> + def_bool n >> + > > Some comments on what arch's want to disable kasan inline would > be helpful and why. Sure, added. Kind regards, Daniel
