a user may need to initiate a manual scan twice via debugfs before
kmemleak reports an orphan object.
this is mentioned in Testing section, let's mention this again in the
Usage section for better visibility.
Link: https://lore.kernel.org/lkml/YMpEtyUP0vuWo9HV@nuc10/
Signed-off-by: Rustam Kovhaev <[email protected]>
---
Documentation/dev-tools/kmemleak.rst | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst
index 1c935f41cd3a..512f78e6e4fb 100644
--- a/Documentation/dev-tools/kmemleak.rst
+++ b/Documentation/dev-tools/kmemleak.rst
@@ -38,6 +38,9 @@ Note that the orphan objects are listed in the order they were allocated
and one object at the beginning of the list may cause other subsequent
objects to be reported as orphan.
+If you are triggering a manual memory scan, you might need to do it at least
+twice before kmemleak reports an orphan object.
+
Memory scanning parameters can be modified at run-time by writing to the
``/sys/kernel/debug/kmemleak`` file. The following parameters are supported:
@@ -235,7 +238,7 @@ enabled. Load the module and perform a scan with::
# modprobe kmemleak-test
# echo scan > /sys/kernel/debug/kmemleak
-Note that the you may not get results instantly or on the first scanning. When
+Note that you may not get the results instantly or on the first scanning. When
kmemleak gets results, it'll log ``kmemleak: <count of leaks> new suspected
memory leaks``. Then read the file to see then::
--
2.30.2
On Thu, Jun 17, 2021 at 02:04:20PM -0700, Rustam Kovhaev wrote:
> a user may need to initiate a manual scan twice via debugfs before
> kmemleak reports an orphan object.
> this is mentioned in Testing section, let's mention this again in the
> Usage section for better visibility.
>
> Link: https://lore.kernel.org/lkml/YMpEtyUP0vuWo9HV@nuc10/
> Signed-off-by: Rustam Kovhaev <[email protected]>
Acked-by: Catalin Marinas <[email protected]>