summaryrefslogtreecommitdiffstats
path: root/mm/early_ioremap.c
diff options
context:
space:
mode:
authorMarco Elver <elver@google.com>2021-11-05 13:45:34 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2022-04-13 20:59:00 +0200
commit105b50d9bb822a788c4af1f6421f4ed17c90d7a2 (patch)
treea4f5af3601f98fa1369fc8f5db87339c40bd4101 /mm/early_ioremap.c
parent44b44b64b4da9edbbfff52872a5b0c10acda54aa (diff)
downloadlinux-stable-105b50d9bb822a788c4af1f6421f4ed17c90d7a2.tar.gz
linux-stable-105b50d9bb822a788c4af1f6421f4ed17c90d7a2.tar.bz2
linux-stable-105b50d9bb822a788c4af1f6421f4ed17c90d7a2.zip
kfence: limit currently covered allocations when pool nearly full
[ Upstream commit 08f6b10630f284755087f58aa393402e15b92977 ] One of KFENCE's main design principles is that with increasing uptime, allocation coverage increases sufficiently to detect previously undetected bugs. We have observed that frequent long-lived allocations of the same source (e.g. pagecache) tend to permanently fill up the KFENCE pool with increasing system uptime, thus breaking the above requirement. The workaround thus far had been increasing the sample interval and/or increasing the KFENCE pool size, but is no reliable solution. To ensure diverse coverage of allocations, limit currently covered allocations of the same source once pool utilization reaches 75% (configurable via `kfence.skip_covered_thresh`) or above. The effect is retaining reasonable allocation coverage when the pool is close to full. A side-effect is that this also limits frequent long-lived allocations of the same source filling up the pool permanently. Uniqueness of an allocation for coverage purposes is based on its (partial) allocation stack trace (the source). A Counting Bloom filter is used to check if an allocation is covered; if the allocation is currently covered, the allocation is skipped by KFENCE. Testing was done using: (a) a synthetic workload that performs frequent long-lived allocations (default config values; sample_interval=1; num_objects=63), and (b) normal desktop workloads on an otherwise idle machine where the problem was first reported after a few days of uptime (default config values). In both test cases the sampled allocation rate no longer drops to zero at any point. In the case of (b) we observe (after 2 days uptime) 15% unique allocations in the pool, 77% pool utilization, with 20% "skipped allocations (covered)". [elver@google.com: simplify and just use hash_32(), use more random stack_hash_seed] Link: https://lkml.kernel.org/r/YU3MRGaCaJiYht5g@elver.google.com [elver@google.com: fix 32 bit] Link: https://lkml.kernel.org/r/20210923104803.2620285-4-elver@google.com Signed-off-by: Marco Elver <elver@google.com> Reviewed-by: Dmitry Vyukov <dvyukov@google.com> Acked-by: Alexander Potapenko <glider@google.com> Cc: Aleksandr Nogikh <nogikh@google.com> Cc: Jann Horn <jannh@google.com> Cc: Taras Madan <tarasmadan@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'mm/early_ioremap.c')
0 files changed, 0 insertions, 0 deletions