All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Elver <elver@google.com>
To: elver@google.com, Andrew Morton <akpm@linux-foundation.org>
Cc: Alexander Potapenko <glider@google.com>,
	Dmitry Vyukov <dvyukov@google.com>, Jann Horn <jannh@google.com>,
	Aleksandr Nogikh <nogikh@google.com>,
	Taras Madan <tarasmadan@google.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	kasan-dev@googlegroups.com
Subject: [PATCH v3 5/5] kfence: add note to documentation about skipping covered allocations
Date: Thu, 23 Sep 2021 12:48:03 +0200	[thread overview]
Message-ID: <20210923104803.2620285-5-elver@google.com> (raw)
In-Reply-To: <20210923104803.2620285-1-elver@google.com>

Add a note briefly mentioning the new policy about "skipping currently
covered allocations if pool close to full." Since this has a notable
impact on KFENCE's bug-detection ability on systems with large uptimes,
it is worth pointing out the feature.

Signed-off-by: Marco Elver <elver@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
---
v2:
* Rewrite.
---
 Documentation/dev-tools/kfence.rst | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/dev-tools/kfence.rst b/Documentation/dev-tools/kfence.rst
index 0fbe3308bf37..d45f952986ae 100644
--- a/Documentation/dev-tools/kfence.rst
+++ b/Documentation/dev-tools/kfence.rst
@@ -269,6 +269,17 @@ tail of KFENCE's freelist, so that the least recently freed objects are reused
 first, and the chances of detecting use-after-frees of recently freed objects
 is increased.
 
+If pool utilization reaches 75% (default) or above, to reduce the risk of the
+pool eventually being fully occupied by allocated objects yet ensure diverse
+coverage of allocations, KFENCE limits currently covered allocations of the
+same source from further filling up the pool. The "source" of an allocation is
+based on its partial allocation stack trace. A side-effect is that this also
+limits frequent long-lived allocations (e.g. pagecache) of the same source
+filling up the pool permanently, which is the most common risk for the pool
+becoming full and the sampled allocation rate dropping to zero. The threshold
+at which to start limiting currently covered allocations can be configured via
+the boot parameter ``kfence.skip_covered_thresh`` (pool usage%).
+
 Interface
 ---------
 
-- 
2.33.0.464.g1972c5931b-goog


  parent reply	other threads:[~2021-09-23 10:48 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-23 10:47 [PATCH v3 1/5] stacktrace: move filter_irq_stacks() to kernel/stacktrace.c Marco Elver
2021-09-23 10:47 ` Marco Elver
2021-09-23 10:48 ` [PATCH v3 2/5] kfence: count unexpectedly skipped allocations Marco Elver
2021-09-23 10:48   ` Marco Elver
2021-09-23 11:15   ` Alexander Potapenko
2021-09-23 11:15     ` Alexander Potapenko
2021-09-23 10:48 ` [PATCH v3 3/5] kfence: move saving stack trace of allocations into __kfence_alloc() Marco Elver
2021-09-23 10:48   ` Marco Elver
2021-09-23 11:32   ` Alexander Potapenko
2021-09-23 11:32     ` Alexander Potapenko
2021-09-23 10:48 ` [PATCH v3 4/5] kfence: limit currently covered allocations when pool nearly full Marco Elver
2021-09-23 10:48   ` Marco Elver
2021-09-23 11:18   ` Dmitry Vyukov
2021-09-23 11:18     ` Dmitry Vyukov
2021-09-23 13:23     ` Alexander Potapenko
2021-09-23 13:23       ` Alexander Potapenko
2021-09-23 13:44       ` Marco Elver
2021-09-23 13:44         ` Marco Elver
2021-09-23 13:46         ` Alexander Potapenko
2021-09-23 13:46           ` Alexander Potapenko
2021-09-23 23:28         ` Andrew Morton
2021-09-24 13:01           ` Marco Elver
2021-09-23 10:48 ` Marco Elver [this message]
2021-09-23 10:48   ` [PATCH v3 5/5] kfence: add note to documentation about skipping covered allocations Marco Elver
2021-09-23 15:46   ` Alexander Potapenko
2021-09-23 15:46     ` Alexander Potapenko
2021-09-23 11:14 ` [PATCH v3 1/5] stacktrace: move filter_irq_stacks() to kernel/stacktrace.c Alexander Potapenko
2021-09-23 11:14   ` Alexander Potapenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210923104803.2620285-5-elver@google.com \
    --to=elver@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=jannh@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nogikh@google.com \
    --cc=tarasmadan@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.