Merge tag 'trace-v5.14-rc4-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rosted...
[linux-2.6-microblaze.git] / lib / Kconfig.kasan
index cffc2eb..1e2d10f 100644 (file)
@@ -12,6 +12,13 @@ config HAVE_ARCH_KASAN_HW_TAGS
 config HAVE_ARCH_KASAN_VMALLOC
        bool
 
+config ARCH_DISABLE_KASAN_INLINE
+       bool
+       help
+         An architecture might not support inline instrumentation.
+         When this option is selected, inline and stack instrumentation are
+         disabled.
+
 config CC_HAS_KASAN_GENERIC
        def_bool $(cc-option, -fsanitize=kernel-address)
 
@@ -130,6 +137,7 @@ config KASAN_OUTLINE
 
 config KASAN_INLINE
        bool "Inline instrumentation"
+       depends on !ARCH_DISABLE_KASAN_INLINE
        help
          Compiler directly inserts code checking shadow memory before
          memory accesses. This is faster than outline (in some workloads
@@ -141,6 +149,7 @@ endchoice
 config KASAN_STACK
        bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
        depends on KASAN_GENERIC || KASAN_SW_TAGS
+       depends on !ARCH_DISABLE_KASAN_INLINE
        default y if CC_IS_GCC
        help
          The LLVM stack address sanitizer has a know problem that
@@ -154,10 +163,13 @@ config KASAN_STACK
          but clang users can still enable it for builds without
          CONFIG_COMPILE_TEST.  On gcc it is assumed to always be safe
          to use and enabled by default.
+         If the architecture disables inline instrumentation, stack
+         instrumentation is also disabled as it adds inline-style
+         instrumentation that is run unconditionally.
 
-config KASAN_SW_TAGS_IDENTIFY
+config KASAN_TAGS_IDENTIFY
        bool "Enable memory corruption identification"
-       depends on KASAN_SW_TAGS
+       depends on KASAN_SW_TAGS || KASAN_HW_TAGS
        help
          This option enables best-effort identification of bug type
          (use-after-free or out-of-bounds) at the cost of increased