docs: add section about KMEMLEAK to syzbot doc

1 files changed, 22 insertions, 0 deletions

diff --git a/docs/syzbot.md b/docs/syzbot.md
index f24e28b1a..82117a04b 100644
--- a/docs/syzbot.md
+++ b/docs/syzbot.md
@@ -306,6 +306,28 @@ email to `syzbot+HASH` address containing the following line:
 ```
 and attach/inline your test patch in the same email.
 
+## Memory leaks
+
+`syzbot` uses `KMEMLEAK` to find memory leaks in the Linux kernel.
+`KMEMLEAK` kernel config is stored [here](/dashboard/config/upstream-leak.config).
+See `KMEMLEAK` [docs](https://www.kernel.org/doc/html/latest/dev-tools/kmemleak.html)
+for general info, algorithm overview and usage instructions.
+
+Memory leaks may be tricky to debug because we have only the allocation stack,
+but we don't see where kernel code forgot to free the object or drop a reference.
+`KMEMLEAK` can have some false positives on tricky kernel code that hides
+pointers to live objects and due to memory scanning non-atomicity.
+But don't write off everything to false positives right away, the rate of
+false positives is observed to be very low. In particular, `KMEMLEAK` is
+[not confused](https://elixir.bootlin.com/linux/v5.2-rc1/source/mm/kmemleak.c#L1426)
+by pointers stored in a middle of another object; and it's
+[not confused](https://elixir.bootlin.com/linux/v5.2-rc1/source/mm/kmemleak.c#L440)
+if several pointer low bits are used as flags because a pointer into
+a middle of an object also marks the target as reachable.
+
+A useful litmus test is to remove `KMEMLEAK` code from the reproducer
+and run it for longer and/or multiple times. If memory consumption and number
+of live objects in `/proc/slabinfo` steadily grow, most likely the leak is real.
 
 ## No custom patches