Revision b5d281f6c16dd432b618bdfd36ddba1a58d5b603 authored by Christian Marangi on 19 June 2022, 22:03:51 UTC, committed by Chanwoo Choi on 29 June 2022, 20:11:17 UTC
On a devfreq PROBE_DEFER, the freq_table in the driver profile struct, is never reset and may be leaved in an undefined state. This comes from the fact that we store the freq_table in the driver profile struct that is commonly defined as static and not reset on PROBE_DEFER. We currently skip the reinit of the freq_table if we found it's already defined since a driver may declare his own freq_table. This logic is flawed in the case devfreq core generate a freq_table, set it in the profile struct and then PROBE_DEFER, freeing the freq_table. In this case devfreq will found a NOT NULL freq_table that has been freed, skip the freq_table generation and probe the driver based on the wrong table. To fix this and correctly handle PROBE_DEFER, use a local freq_table and max_state in the devfreq struct and never modify the freq_table present in the profile struct if it does provide it. Fixes: 0ec09ac2cebe ("PM / devfreq: Set the freq_table of devfreq device") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
1 parent f44b799
Kconfig.kasan
# SPDX-License-Identifier: GPL-2.0-only
# This config refers to the generic KASAN mode.
config HAVE_ARCH_KASAN
bool
config HAVE_ARCH_KASAN_SW_TAGS
bool
config HAVE_ARCH_KASAN_HW_TAGS
bool
config HAVE_ARCH_KASAN_VMALLOC
bool
config ARCH_DISABLE_KASAN_INLINE
bool
help
Disables both inline and stack instrumentation. Selected by
architectures that do not support these instrumentation types.
config CC_HAS_KASAN_GENERIC
def_bool $(cc-option, -fsanitize=kernel-address)
config CC_HAS_KASAN_SW_TAGS
def_bool $(cc-option, -fsanitize=kernel-hwaddress)
# This option is only required for software KASAN modes.
# Old GCC versions do not have proper support for no_sanitize_address.
# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89124 for details.
config CC_HAS_WORKING_NOSANITIZE_ADDRESS
def_bool !CC_IS_GCC || GCC_VERSION >= 80300
menuconfig KASAN
bool "KASAN: dynamic memory safety error detector"
depends on (((HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC) || \
(HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS)) && \
CC_HAS_WORKING_NOSANITIZE_ADDRESS) || \
HAVE_ARCH_KASAN_HW_TAGS
depends on (SLUB && SYSFS) || (SLAB && !DEBUG_SLAB)
select STACKDEPOT_ALWAYS_INIT
help
Enables KASAN (Kernel Address Sanitizer) - a dynamic memory safety
error detector designed to find out-of-bounds and use-after-free bugs.
See Documentation/dev-tools/kasan.rst for details.
For better error reports, also enable CONFIG_STACKTRACE.
if KASAN
choice
prompt "KASAN mode"
default KASAN_GENERIC
help
KASAN has three modes:
1. Generic KASAN (supported by many architectures, enabled with
CONFIG_KASAN_GENERIC, similar to userspace ASan),
2. Software Tag-Based KASAN (arm64 only, based on software memory
tagging, enabled with CONFIG_KASAN_SW_TAGS, similar to userspace
HWASan), and
3. Hardware Tag-Based KASAN (arm64 only, based on hardware memory
tagging, enabled with CONFIG_KASAN_HW_TAGS).
See Documentation/dev-tools/kasan.rst for details about each mode.
config KASAN_GENERIC
bool "Generic KASAN"
depends on HAVE_ARCH_KASAN && CC_HAS_KASAN_GENERIC
depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
select SLUB_DEBUG if SLUB
select CONSTRUCTORS
help
Enables Generic KASAN.
Requires GCC 8.3.0+ or Clang.
Consumes about 1/8th of available memory at kernel start and adds an
overhead of ~50% for dynamic allocations.
The performance slowdown is ~x3.
(Incompatible with CONFIG_DEBUG_SLAB: the kernel does not boot.)
config KASAN_SW_TAGS
bool "Software Tag-Based KASAN"
depends on HAVE_ARCH_KASAN_SW_TAGS && CC_HAS_KASAN_SW_TAGS
depends on CC_HAS_WORKING_NOSANITIZE_ADDRESS
select SLUB_DEBUG if SLUB
select CONSTRUCTORS
help
Enables Software Tag-Based KASAN.
Requires GCC 11+ or Clang.
Supported only on arm64 CPUs and relies on Top Byte Ignore.
Consumes about 1/16th of available memory at kernel start and
add an overhead of ~20% for dynamic allocations.
May potentially introduce problems related to pointer casting and
comparison, as it embeds a tag into the top byte of each pointer.
(Incompatible with CONFIG_DEBUG_SLAB: the kernel does not boot.)
config KASAN_HW_TAGS
bool "Hardware Tag-Based KASAN"
depends on HAVE_ARCH_KASAN_HW_TAGS
depends on SLUB
help
Enables Hardware Tag-Based KASAN.
Requires GCC 10+ or Clang 12+.
Supported only on arm64 CPUs starting from ARMv8.5 and relies on
Memory Tagging Extension and Top Byte Ignore.
Consumes about 1/32nd of available memory.
May potentially introduce problems related to pointer casting and
comparison, as it embeds a tag into the top byte of each pointer.
endchoice
choice
prompt "Instrumentation type"
depends on KASAN_GENERIC || KASAN_SW_TAGS
default KASAN_OUTLINE
config KASAN_OUTLINE
bool "Outline instrumentation"
help
Makes the compiler insert function calls that check whether the memory
is accessible before each memory access. Slower than KASAN_INLINE, but
does not bloat the size of the kernel's .text section so much.
config KASAN_INLINE
bool "Inline instrumentation"
depends on !ARCH_DISABLE_KASAN_INLINE
help
Makes the compiler directly insert memory accessibility checks before
each memory access. Faster than KASAN_OUTLINE (gives ~x2 boost for
some workloads), but makes the kernel's .text size much bigger.
endchoice
config KASAN_STACK
bool "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
Disables stack instrumentation and thus KASAN's ability to detect
out-of-bounds bugs in stack variables.
With Clang, stack instrumentation has a problem that causes excessive
stack usage, see https://bugs.llvm.org/show_bug.cgi?id=38809. Thus,
with Clang, this option is deemed unsafe.
This option is always disabled when compile-testing with Clang to
avoid cluttering the log with stack overflow warnings.
With GCC, enabling stack instrumentation is assumed to be safe.
If the architecture disables inline instrumentation via
ARCH_DISABLE_KASAN_INLINE, stack instrumentation gets disabled
as well, as it adds inline-style instrumentation that is run
unconditionally.
config KASAN_TAGS_IDENTIFY
bool "Memory corruption type identification"
depends on KASAN_SW_TAGS || KASAN_HW_TAGS
help
Enables best-effort identification of the bug types (use-after-free
or out-of-bounds) at the cost of increased memory consumption.
Only applicable for the tag-based KASAN modes.
config KASAN_VMALLOC
bool "Check accesses to vmalloc allocations"
depends on HAVE_ARCH_KASAN_VMALLOC
help
Makes KASAN check the validity of accesses to vmalloc allocations.
With software KASAN modes, all types vmalloc allocations are
checked. Enabling this option leads to higher memory usage.
With Hardware Tag-Based KASAN, only non-executable VM_ALLOC mappings
are checked. There is no additional memory usage.
config KASAN_KUNIT_TEST
tristate "KUnit-compatible tests of KASAN bug detection capabilities" if !KUNIT_ALL_TESTS
depends on KASAN && KUNIT
default KUNIT_ALL_TESTS
help
A KUnit-based KASAN test suite. Triggers different kinds of
out-of-bounds and use-after-free accesses. Useful for testing whether
KASAN can detect certain bug types.
For more information on KUnit and unit tests in general, please refer
to the KUnit documentation in Documentation/dev-tools/kunit/.
config KASAN_MODULE_TEST
tristate "KUnit-incompatible tests of KASAN bug detection capabilities"
depends on m && KASAN && !KASAN_HW_TAGS
help
A part of the KASAN test suite that is not integrated with KUnit.
Incompatible with Hardware Tag-Based KASAN.
endif # KASAN
Computing file changes ...