+ radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

+ radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Andrew Morton]

The patch titled
     Subject: radix-tree: fix kmemleak false positives on tree head reassignment
has been added to the -mm mm-new branch.  Its filename is
     radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch

This patch will later appear in the mm-new branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Note, mm-new is a provisional staging ground for work-in-progress
patches, and acceptance into mm-new is a notification for others take
notice and to finish up reviews.  Please do not hesitate to respond to
review feedback and post updated versions to replace or incrementally
fixup patches in mm-new.

The mm-new branch of mm.git is not included in linux-next

If a few days of testing in mm-new is successful, the patch will me moved
into mm.git's mm-unstable branch, which is included in linux-next

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days

------------------------------------------------------
From: Breno Leitao <leitao@debian.org>
Subject: radix-tree: fix kmemleak false positives on tree head reassignment
Date: Thu, 02 Jul 2026 05:58:34 -0700

Kmemleak periodically reports transient false positives for radix tree
nodes allocated through the IDR, for example:

  unreferenced object 0xffff0004d6ac4200 (size 576):
    comm "tcpeventd", pid 6412
    backtrace (crc 335d668a):
      kmem_cache_alloc_noprof
      radix_tree_node_alloc
      radix_tree_extend
      idr_get_free
      idr_alloc_cyclic
      map_create
      __sys_bpf

radix_tree_extend() (grow) and radix_tree_shrink() (shrink) repoint
root->xa_head to a new node.  If a kmemleak scan has already walked past
root->xa_head, the new head is not reachable from any scanned pointer
until the following scan, so kmemleak reports it as leaked even though it
is live.

This is the same race fixed for the XArray API in commit a1a029bcea59
("XArray: fix kmemleak false positive in xas_shrink()").  The IDR uses the
radix tree API directly and hits it on both the grow and the shrink path,
so mark the new head as a transient leak in both.

Link: https://lore.kernel.org/20260702-radix-tree-v1-1-a87c125b0f96@debian.org
Signed-off-by: Breno Leitao <leitao@debian.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 lib/radix-tree.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/lib/radix-tree.c~radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment
+++ a/lib/radix-tree.c
@@ -455,6 +455,8 @@ static int radix_tree_extend(struct radi
 		node->slots[0] = (void __rcu *)entry;
 		entry = node_to_entry(node);
 		rcu_assign_pointer(root->xa_head, entry);
+		/* new head may be missed by an in-progress kmemleak scan */
+		kmemleak_transient_leak(node);
 		shift += RADIX_TREE_MAP_SHIFT;
 	} while (shift <= maxshift);
 out:
@@ -495,8 +497,11 @@ static inline bool radix_tree_shrink(str
 		if (!node->shift && is_idr(root))
 			break;
 
-		if (radix_tree_is_internal_node(child))
+		if (radix_tree_is_internal_node(child)) {
 			entry_to_node(child)->parent = NULL;
+			/* new head may be missed by an in-progress kmemleak scan */
+			kmemleak_transient_leak(entry_to_node(child));
+		}
 
 		/*
 		 * We don't need rcu_assign_pointer(), since we are simply
_

Patches currently in -mm which might be from leitao@debian.org are

mm-kmemleak-avoid-soft-lockup-when-scanning-task-stacks.patch
mm-kmemleak-stop-the-task-stack-scan-early-when-interrupted.patch
mm-kmemleak-stop-the-per-cpu-and-struct-page-scans-early-too.patch
mm-memory-failure-drop-dead-error_states-entry-for-reserved-pages.patch
mm-memory-failure-surface-unhandlable-kernel-pages-as-enotrecoverable.patch
mm-memory-failure-report-mf_msg_kernel-for-unrecoverable-kernel-pages.patch
mm-memory-failure-add-panic-option-for-unrecoverable-pages.patch
documentation-document-panic_on_unrecoverable_memory_failure-sysctl.patch
selftests-mm-add-hwpoison-panic-destructive-test.patch
mm-kmemleak-skip-the-remaining-scan-phases-when-interrupted.patch
radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch

Re: + radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Breno Leitao]

On Thu, Jul 02, 2026 at 03:42:11PM -0700, Andrew Morton wrote:
> 
> The patch titled
>      Subject: radix-tree: fix kmemleak false positives on tree head reassignment
> has been added to the -mm mm-new branch.  Its filename is
>      radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch

Andrew, would you mind replacing it by v2?

V1 didn't have included kmemleak transient function in userspace headers
(tools/testing/shared/linux/kmemleak.h), thus, userspace test were
failing, as reported by:

	https://lore.kernel.org/all/202607031019.AffpLUyg-lkp@intel.com/

V2 was already sent to the list:

	https://lore.kernel.org/all/20260703-radix-tree-v2-1-38bb6efb5f6e@debian.org/

Thanks and sorry for the noise,
--breno

+ radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Andrew Morton]

The patch titled
     Subject: radix-tree: fix kmemleak false positives on tree head reassignment
has been added to the -mm mm-new branch.  Its filename is
     radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch

This patch will later appear in the mm-new branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Note, mm-new is a provisional staging ground for work-in-progress
patches, and acceptance into mm-new is a notification for others take
notice and to finish up reviews.  Please do not hesitate to respond to
review feedback and post updated versions to replace or incrementally
fixup patches in mm-new.

The mm-new branch of mm.git is not included in linux-next

If a few days of testing in mm-new is successful, the patch will me moved
into mm.git's mm-unstable branch, which is included in linux-next

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days

------------------------------------------------------
From: Breno Leitao <leitao@debian.org>
Subject: radix-tree: fix kmemleak false positives on tree head reassignment
Date: Fri, 03 Jul 2026 08:22:03 -0700

Kmemleak periodically reports transient false positives for radix tree
nodes allocated through the IDR, for example:

  unreferenced object 0xffff0004d6ac4200 (size 576):
    comm "tcpeventd", pid 6412
    backtrace (crc 335d668a):
      kmem_cache_alloc_noprof
      radix_tree_node_alloc
      radix_tree_extend
      idr_get_free
      idr_alloc_cyclic
      map_create
      __sys_bpf

radix_tree_extend() (grow) and radix_tree_shrink() (shrink) repoint
root->xa_head to a new node.  If a kmemleak scan has already walked past
root->xa_head, the new head is not reachable from any scanned pointer
until the following scan, so kmemleak reports it as leaked even though it
is live.

This is the same race fixed for the XArray API in commit a1a029bcea59
("XArray: fix kmemleak false positive in xas_shrink()").  The IDR uses the
radix tree API directly and hits it on both the grow and the shrink path,
so mark the new head as a transient leak in both.

Add a matching kmemleak_transient_leak() stub to the radix tree test
harness so the userspace lib/radix-tree.c build keeps building.

Link: https://lore.kernel.org/20260703-radix-tree-v2-1-38bb6efb5f6e@debian.org
Signed-off-by: Breno Leitao <leitao@debian.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 lib/radix-tree.c                      |    7 ++++++-
 tools/testing/shared/linux/kmemleak.h |    1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

--- a/lib/radix-tree.c~radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment
+++ a/lib/radix-tree.c
@@ -455,6 +455,8 @@ static int radix_tree_extend(struct radi
 		node->slots[0] = (void __rcu *)entry;
 		entry = node_to_entry(node);
 		rcu_assign_pointer(root->xa_head, entry);
+		/* new head may be missed by an in-progress kmemleak scan */
+		kmemleak_transient_leak(node);
 		shift += RADIX_TREE_MAP_SHIFT;
 	} while (shift <= maxshift);
 out:
@@ -495,8 +497,11 @@ static inline bool radix_tree_shrink(str
 		if (!node->shift && is_idr(root))
 			break;
 
-		if (radix_tree_is_internal_node(child))
+		if (radix_tree_is_internal_node(child)) {
 			entry_to_node(child)->parent = NULL;
+			/* new head may be missed by an in-progress kmemleak scan */
+			kmemleak_transient_leak(entry_to_node(child));
+		}
 
 		/*
 		 * We don't need rcu_assign_pointer(), since we are simply
--- a/tools/testing/shared/linux/kmemleak.h~radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment
+++ a/tools/testing/shared/linux/kmemleak.h
@@ -1 +1,2 @@
 static inline void kmemleak_update_trace(const void *ptr) { }
+static inline void kmemleak_transient_leak(const void *ptr) { }
_

Patches currently in -mm which might be from leitao@debian.org are

mm-kmemleak-fix-checksum-computation-for-per-cpu-objects.patch
mm-kmemleak-avoid-soft-lockup-when-scanning-task-stacks.patch
mm-kmemleak-stop-the-task-stack-scan-early-when-interrupted.patch
mm-kmemleak-stop-the-per-cpu-and-struct-page-scans-early-too.patch
mm-memory-failure-drop-dead-error_states-entry-for-reserved-pages.patch
mm-memory-failure-surface-unhandlable-kernel-pages-as-enotrecoverable.patch
mm-memory-failure-report-mf_msg_kernel-for-unrecoverable-kernel-pages.patch
mm-memory-failure-add-panic-option-for-unrecoverable-pages.patch
documentation-document-panic_on_unrecoverable_memory_failure-sysctl.patch
selftests-mm-add-hwpoison-panic-destructive-test.patch
mm-kmemleak-skip-the-remaining-scan-phases-when-interrupted.patch
radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch

+ radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Andrew Morton]

The patch titled
     Subject: radix-tree: fix kmemleak false positives on tree head reassignment
has been added to the -mm mm-new branch.  Its filename is
     radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch

This patch will shortly appear at
     https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch

This patch will later appear in the mm-new branch at
    git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

Note, mm-new is a provisional staging ground for work-in-progress
patches, and acceptance into mm-new is a notification for others take
notice and to finish up reviews.  Please do not hesitate to respond to
review feedback and post updated versions to replace or incrementally
fixup patches in mm-new.

The mm-new branch of mm.git is not included in linux-next

If a few days of testing in mm-new is successful, the patch will me moved
into mm.git's mm-unstable branch, which is included in linux-next

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***

The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days

------------------------------------------------------
From: Breno Leitao <leitao@debian.org>
Subject: radix-tree: fix kmemleak false positives on tree head reassignment
Date: Fri, 03 Jul 2026 08:22:03 -0700

Kmemleak periodically reports transient false positives for radix tree
nodes allocated through the IDR, for example:

  unreferenced object 0xffff0004d6ac4200 (size 576):
    comm "tcpeventd", pid 6412
    backtrace (crc 335d668a):
      kmem_cache_alloc_noprof
      radix_tree_node_alloc
      radix_tree_extend
      idr_get_free
      idr_alloc_cyclic
      map_create
      __sys_bpf

radix_tree_extend() (grow) and radix_tree_shrink() (shrink) repoint
root->xa_head to a new node.  If a kmemleak scan has already walked past
root->xa_head, the new head is not reachable from any scanned pointer
until the following scan, so kmemleak reports it as leaked even though it
is live.

This is the same race fixed for the XArray API in commit a1a029bcea59
("XArray: fix kmemleak false positive in xas_shrink()").  The IDR uses the
radix tree API directly and hits it on both the grow and the shrink path,
so mark the new head as a transient leak in both.

Add a matching kmemleak_transient_leak() stub to the radix tree test
harness so the userspace lib/radix-tree.c build keeps building.

Link: https://lore.kernel.org/20260703-radix-tree-v2-1-38bb6efb5f6e@debian.org
Signed-off-by: Breno Leitao <leitao@debian.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Matthew Wilcox <willy@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 lib/radix-tree.c                      |    7 ++++++-
 tools/testing/shared/linux/kmemleak.h |    1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

--- a/lib/radix-tree.c~radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment
+++ a/lib/radix-tree.c
@@ -455,6 +455,8 @@ static int radix_tree_extend(struct radi
 		node->slots[0] = (void __rcu *)entry;
 		entry = node_to_entry(node);
 		rcu_assign_pointer(root->xa_head, entry);
+		/* new head may be missed by an in-progress kmemleak scan */
+		kmemleak_transient_leak(node);
 		shift += RADIX_TREE_MAP_SHIFT;
 	} while (shift <= maxshift);
 out:
@@ -495,8 +497,11 @@ static inline bool radix_tree_shrink(str
 		if (!node->shift && is_idr(root))
 			break;
 
-		if (radix_tree_is_internal_node(child))
+		if (radix_tree_is_internal_node(child)) {
 			entry_to_node(child)->parent = NULL;
+			/* new head may be missed by an in-progress kmemleak scan */
+			kmemleak_transient_leak(entry_to_node(child));
+		}
 
 		/*
 		 * We don't need rcu_assign_pointer(), since we are simply
--- a/tools/testing/shared/linux/kmemleak.h~radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment
+++ a/tools/testing/shared/linux/kmemleak.h
@@ -1 +1,2 @@
 static inline void kmemleak_update_trace(const void *ptr) { }
+static inline void kmemleak_transient_leak(const void *ptr) { }
_

Patches currently in -mm which might be from leitao@debian.org are

mm-kmemleak-fix-checksum-computation-for-per-cpu-objects.patch
mm-kmemleak-avoid-soft-lockup-when-scanning-task-stacks.patch
mm-kmemleak-stop-the-task-stack-scan-early-when-interrupted.patch
mm-kmemleak-stop-the-per-cpu-and-struct-page-scans-early-too.patch
mm-memory-failure-drop-dead-error_states-entry-for-reserved-pages.patch
mm-memory-failure-surface-unhandlable-kernel-pages-as-enotrecoverable.patch
mm-memory-failure-report-mf_msg_kernel-for-unrecoverable-kernel-pages.patch
mm-memory-failure-add-panic-option-for-unrecoverable-pages.patch
documentation-document-panic_on_unrecoverable_memory_failure-sysctl.patch
selftests-mm-add-hwpoison-panic-destructive-test.patch
mm-kmemleak-skip-the-remaining-scan-phases-when-interrupted.patch
radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch

Re: + radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Matthew Wilcox]

On Sat, Jul 04, 2026 at 07:12:40PM -0700, Andrew Morton wrote:
> The patch titled
>      Subject: radix-tree: fix kmemleak false positives on tree head reassignment
> has been added to the -mm mm-new branch.  Its filename is
>      radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch

Umm.  I don't see this patch in my inbox anywhere else.  Is email broken
again?

> From: Breno Leitao <leitao@debian.org>
> Subject: radix-tree: fix kmemleak false positives on tree head reassignment
> Date: Fri, 03 Jul 2026 08:22:03 -0700
> 
> Kmemleak periodically reports transient false positives for radix tree
> nodes allocated through the IDR, for example:
> 
>   unreferenced object 0xffff0004d6ac4200 (size 576):
>     comm "tcpeventd", pid 6412
>     backtrace (crc 335d668a):
>       kmem_cache_alloc_noprof
>       radix_tree_node_alloc
>       radix_tree_extend
>       idr_get_free
>       idr_alloc_cyclic
>       map_create
>       __sys_bpf
> 
> radix_tree_extend() (grow) and radix_tree_shrink() (shrink) repoint
> root->xa_head to a new node.  If a kmemleak scan has already walked past
> root->xa_head, the new head is not reachable from any scanned pointer
> until the following scan, so kmemleak reports it as leaked even though it
> is live.
> 
> This is the same race fixed for the XArray API in commit a1a029bcea59

This commit ID doesn't exist in any tree I have.

> ("XArray: fix kmemleak false positive in xas_shrink()").  The IDR uses the
> radix tree API directly and hits it on both the grow and the shrink path,
> so mark the new head as a transient leak in both.
> 
> Add a matching kmemleak_transient_leak() stub to the radix tree test
> harness so the userspace lib/radix-tree.c build keeps building.

Last time this was proposed, the suggestion was that kmemleak needed to
be fixed.

https://lore.kernel.org/all/aCyI8T2sWlPLEYZ_@arm.com/

Re: + radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Andrew Morton]

On Sun, 5 Jul 2026 11:45:04 +0100 Matthew Wilcox <willy@infradead.org> wrote:

> On Sat, Jul 04, 2026 at 07:12:40PM -0700, Andrew Morton wrote:
> > The patch titled
> >      Subject: radix-tree: fix kmemleak false positives on tree head reassignment
> > has been added to the -mm mm-new branch.  Its filename is
> >      radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch
> 
> Umm.  I don't see this patch in my inbox anywhere else.  Is email broken
> again?

You weren't cc'ed on the original.  I added you.  lib/radix-tree.c has
no MAINTAINERS record!

> > This is the same race fixed for the XArray API in commit a1a029bcea59
> 
> This commit ID doesn't exist in any tree I have.
> 
> > ("XArray: fix kmemleak false positive in xas_shrink()").  The IDR uses the
> > radix tree API directly and hits it on both the grow and the shrink path,
> > so mark the new head as a transient leak in both.

https://patchew.org/linux/20250512191707.245153-1-jkangas@redhat.com/

Seems it was in mm.git for a while, I dropped it due to failures and
I don't think Jared took it further.

> > Add a matching kmemleak_transient_leak() stub to the radix tree test
> > harness so the userspace lib/radix-tree.c build keeps building.
> 
> Last time this was proposed, the suggestion was that kmemleak needed to
> be fixed.
> 
> https://lore.kernel.org/all/aCyI8T2sWlPLEYZ_@arm.com/

Great, thanks, I added a note, shall await developments.

Re: + radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Breno Leitao]

Hello Willy,

On Sun, Jul 05, 2026 at 11:45:04AM +0100, Matthew Wilcox wrote:
> > Add a matching kmemleak_transient_leak() stub to the radix tree test
> > harness so the userspace lib/radix-tree.c build keeps building.
>
> Last time this was proposed, the suggestion was that kmemleak needed to
> be fixed.
>
> https://lore.kernel.org/all/aCyI8T2sWlPLEYZ_@arm.com/

My understanding from that thread is that kmemleak could be made more
reliable by explicitly waiting for a rescan before reporting (which it
is a great addition).

This patch explictly tell kmemleak that this object will be temporarily
unreferenced, which is more cooperative.

That said, I believe both approaches. This transient-leak annotation and
Catalin's earlier proposal—can coexist as complementary mechanisms to
reduce kmemleak false positives (which has been my goal, given I run
kmemleak-enabled kernel at some scale)

Re: + radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Catalin Marinas]

On Mon, Jul 06, 2026 at 03:41:54AM -0700, Breno Leitao wrote:
> On Sun, Jul 05, 2026 at 11:45:04AM +0100, Matthew Wilcox wrote:
> > > Add a matching kmemleak_transient_leak() stub to the radix tree test
> > > harness so the userspace lib/radix-tree.c build keeps building.
> >
> > Last time this was proposed, the suggestion was that kmemleak needed to
> > be fixed.
> >
> > https://lore.kernel.org/all/aCyI8T2sWlPLEYZ_@arm.com/
> 
> My understanding from that thread is that kmemleak could be made more
> reliable by explicitly waiting for a rescan before reporting (which it
> is a great addition).
> 
> This patch explictly tell kmemleak that this object will be temporarily
> unreferenced, which is more cooperative.
> 
> That said, I believe both approaches. This transient-leak annotation and
> Catalin's earlier proposal—can coexist as complementary mechanisms to
> reduce kmemleak false positives (which has been my goal, given I run
> kmemleak-enabled kernel at some scale)

I'm not happy with the transient leak annotations either but couldn't
come up with something better. The last year's proposal to reset the
checksum pretty much forces it to go through one more scan, something
your patches already do, though maybe we could change the default.

I wonder whether we should force the scanning to happen twice in a row
and drop the min_unref_count. Those transient leaks happen because of
some micro/milliseconds miss of a pointer. If we have new white objects
of the end of a scan, go one more round through the root and gray
objects (but do not reset them to white) and only then report the leaks.
If the white objects have been reported already or we don't have any
left, skip this additional scan or bail out early. We could have a
tunable for this one to go 2-3 times if needed, though I guess twice is
sufficient. The interface is also preserved as you do an echo scan only
once (or twice initially with the checksum calculation).

-- 
Catalin

Re: + radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Breno Leitao]

Hello Catalin,

On Mon, Jul 06, 2026 at 12:39:30PM +0100, Catalin Marinas wrote:
> On Mon, Jul 06, 2026 at 03:41:54AM -0700, Breno Leitao wrote:
> > On Sun, Jul 05, 2026 at 11:45:04AM +0100, Matthew Wilcox wrote:
> > > > Add a matching kmemleak_transient_leak() stub to the radix tree test
> > > > harness so the userspace lib/radix-tree.c build keeps building.
> > >
> > > Last time this was proposed, the suggestion was that kmemleak needed to
> > > be fixed.
> > >
> > > https://lore.kernel.org/all/aCyI8T2sWlPLEYZ_@arm.com/
> > 
> > My understanding from that thread is that kmemleak could be made more
> > reliable by explicitly waiting for a rescan before reporting (which it
> > is a great addition).
> > 
> > This patch explictly tell kmemleak that this object will be temporarily
> > unreferenced, which is more cooperative.
> > 
> > That said, I believe both approaches. This transient-leak annotation and
> > Catalin's earlier proposal—can coexist as complementary mechanisms to
> > reduce kmemleak false positives (which has been my goal, given I run
> > kmemleak-enabled kernel at some scale)
> 
> I'm not happy with the transient leak annotations either but couldn't
> come up with something better. The last year's proposal to reset the
> checksum pretty much forces it to go through one more scan, something
> your patches already do, though maybe we could change the default.
> 
> I wonder whether we should force the scanning to happen twice in a row
> and drop the min_unref_count. Those transient leaks happen because of
> some micro/milliseconds miss of a pointer. If we have new white objects
> of the end of a scan, go one more round through the root and gray
> objects (but do not reset them to white) and only then report the leaks.
> If the white objects have been reported already or we don't have any
> left, skip this additional scan or bail out early. We could have a
> tunable for this one to go 2-3 times if needed, though I guess twice is
> sufficient. The interface is also preserved as you do an echo scan only
> once (or twice initially with the checksum calculation).

That is a good proposal, and I am happy to hack it up.

On the other side, I _think_ we want to have both approaches
(your rescan-after-white) and min_unref_count. They serve different
purposes. This is how I see them serving different purposes:

1) This rescan-after-white proposal:

  Target: Developers that cat manually scanning for leaks when they
  develop something.

    a) The goal is to produce a memory leaks after the scan is done.
    b) Latency is more important than false positives
    c) min_unref_count = 1

2) min_unref_count 

  Target: Production servers running kmemleak on some cloud "probe
  points", where the service will run for hours/days.

    a) Latency is not important (system is automatically deployed and
    tested)
    b) False positives is heavily undesirable. It causes an alarm to get
    some engineer to investigate.
    c) In this case min_unref_count will be super high (>10)
      - I.e, just report when you are pretty sure this is a real issue.
   
Anyway, that's what I'm seeing from my angle. Let me know if I'm way
off.

Re: + radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Catalin Marinas]

On Mon, Jul 06, 2026 at 07:53:30AM -0700, Breno Leitao wrote:
> On Mon, Jul 06, 2026 at 12:39:30PM +0100, Catalin Marinas wrote:
> > I wonder whether we should force the scanning to happen twice in a row
> > and drop the min_unref_count. Those transient leaks happen because of
> > some micro/milliseconds miss of a pointer. If we have new white objects
> > of the end of a scan, go one more round through the root and gray
> > objects (but do not reset them to white) and only then report the leaks.
> > If the white objects have been reported already or we don't have any
> > left, skip this additional scan or bail out early. We could have a
> > tunable for this one to go 2-3 times if needed, though I guess twice is
> > sufficient. The interface is also preserved as you do an echo scan only
> > once (or twice initially with the checksum calculation).
> 
> That is a good proposal, and I am happy to hack it up.
> 
> On the other side, I _think_ we want to have both approaches
> (your rescan-after-white) and min_unref_count. They serve different
> purposes. This is how I see them serving different purposes:
> 
> 1) This rescan-after-white proposal:
> 
>   Target: Developers that cat manually scanning for leaks when they
>   develop something.
> 
>     a) The goal is to produce a memory leaks after the scan is done.
>     b) Latency is more important than false positives
>     c) min_unref_count = 1
> 
> 2) min_unref_count 
> 
>   Target: Production servers running kmemleak on some cloud "probe
>   points", where the service will run for hours/days.
> 
>     a) Latency is not important (system is automatically deployed and
>     tested)
>     b) False positives is heavily undesirable. It causes an alarm to get
>     some engineer to investigate.
>     c) In this case min_unref_count will be super high (>10)
>       - I.e, just report when you are pretty sure this is a real issue.
>    
> Anyway, that's what I'm seeing from my angle. Let me know if I'm way
> off.

You are right. If you only ever use min_unref_count of 2, then the first
option might be alright but for larger numbers, you can't just keep
scanning 10 times in a row. If option 1 works, we might be able to get
rid of the transient leak annotations.

I got Claude to refactor for the first idea and it mostly works. For
some reason, after modprobe kmemleak-test, it always does the
confirmation scan. There's an object (vmalloc) left that's reported as
a potential leak candidate but not confirmed in the subsequent scan.
I'll check tomorrow, need to finish the day early.

Pasting the diff I was playing with below for reference (with some debug
printks):

---------------8<--------------------
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 7c7ba17ce7af..fad0a01ddbcf 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1797,13 +1797,13 @@ static void dedup_flush(struct xarray *dedup)
  * kernel's standard allocators. This function must be called with the
  * scan_mutex held.
  */
-static void kmemleak_scan(void)
+static void __kmemleak_scan(bool full)
 {
 	struct kmemleak_object *object;
 	struct zone *zone;
 	int __maybe_unused i;
-	struct xarray dedup;
-	int new_leaks = 0;
+
+	printk("### %s scan started\n", full ? "full" : "confirmation");
 
 	jiffies_last_scan = jiffies;
 
@@ -1833,8 +1833,13 @@ static void kmemleak_scan(void)
 				__paint_it(object, KMEMLEAK_BLACK);
 		}
 
-		/* reset the reference count (whiten the object) */
-		object->count = 0;
+		/*
+		 * Reset the reference count (whiten the object). A confirmation
+		 * scan re-tests only the objects still white, keeping (and
+		 * re-scanning) the references already found by the full scan.
+		 */
+		if (full || color_white(object))
+			object->count = 0;
 		if (color_gray(object) && get_object(object))
 			list_add_tail(&object->gray_list, &gray_list);
 
@@ -1904,6 +1909,10 @@ static void kmemleak_scan(void)
 	 */
 	scan_gray_list();
 
+	/* a confirmation scan does not look for modified objects */
+	if (!full)
+		return;
+
 	/*
 	 * Check for new or unreferenced objects modified since the previous
 	 * scan and color them gray until the next scan.
@@ -1935,6 +1944,47 @@ static void kmemleak_scan(void)
 	 * Re-scan the gray list for modified unreferenced objects.
 	 */
 	scan_gray_list();
+}
+
+/*
+ * Return true if the last scan left any object that would be reported as a
+ * leak. Racy: it only gates the optional confirmation scan.
+ */
+static bool kmemleak_has_candidates(void)
+{
+	struct kmemleak_object *object;
+	int candidates = 0;
+
+	rcu_read_lock();
+	list_for_each_entry_rcu(object, &object_list, object_list) {
+		if (unreferenced_object(object) &&
+		    !(object->flags & OBJECT_REPORTED)) {
+			candidates++;
+			printk("### candidate 0x%px size %zu comm %s\n",
+			       (void *)object->pointer, object->size,
+			       object->comm);
+		}
+		if (need_resched())
+			kmemleak_cond_resched(object);
+	}
+	rcu_read_unlock();
+
+	printk("### has_candidates: %d\n", candidates);
+	return candidates != 0;
+}
+
+/*
+ * Scan the memory and report the unreferenced objects as leaks. Must be
+ * called with the scan_mutex held.
+ */
+static void kmemleak_scan(void)
+{
+	struct kmemleak_object *object;
+	struct xarray dedup;
+	int new_leaks = 0;
+
+	printk("### ===== scan start =====\n");
+	__kmemleak_scan(true);
 
 	/*
 	 * If scanning was stopped do not report any new unreferenced objects.
@@ -1942,6 +1992,20 @@ static void kmemleak_scan(void)
 	if (scan_should_stop())
 		return;
 
+	/*
+	 * The marking phase is not atomic: a live object whose only reference
+	 * is moved by a concurrent RCU update can be missed for one scan and
+	 * reported as a transient false positive. If a leak is suspected, mark
+	 * again keeping the references already found; an object referenced by
+	 * either scan is not reported, a genuine leak (white in both) still is.
+	 */
+	if (kmemleak_has_candidates()) {
+		printk("### running confirmation scan\n");
+		__kmemleak_scan(false);
+		if (scan_should_stop())
+			return;
+	}
+
 	/*
 	 * Scanning result reporting. When verbose printing is enabled, dedupe
 	 * by stackdepot trace_handle so each unique backtrace is logged once
@@ -1971,6 +2035,9 @@ static void kmemleak_scan(void)
 		if (unreferenced_object(object) &&
 		    !(object->flags & OBJECT_REPORTED)) {
 			object->flags |= OBJECT_REPORTED;
+			printk("### reported 0x%px size %zu comm %s\n",
+			       (void *)object->pointer, object->size,
+			       object->comm);
 			if (kmemleak_verbose) {
 				trace_handle = object->trace_handle;
 				dedup_print = true;

Re: + radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Catalin Marinas]

On Mon, Jul 06, 2026 at 05:25:25PM +0100, Catalin Marinas wrote:
> On Mon, Jul 06, 2026 at 07:53:30AM -0700, Breno Leitao wrote:
> > On Mon, Jul 06, 2026 at 12:39:30PM +0100, Catalin Marinas wrote:
> > > I wonder whether we should force the scanning to happen twice in a row
> > > and drop the min_unref_count. Those transient leaks happen because of
> > > some micro/milliseconds miss of a pointer. If we have new white objects
> > > of the end of a scan, go one more round through the root and gray
> > > objects (but do not reset them to white) and only then report the leaks.
> > > If the white objects have been reported already or we don't have any
> > > left, skip this additional scan or bail out early. We could have a
> > > tunable for this one to go 2-3 times if needed, though I guess twice is
> > > sufficient. The interface is also preserved as you do an echo scan only
> > > once (or twice initially with the checksum calculation).
> > 
> > That is a good proposal, and I am happy to hack it up.
> > 
> > On the other side, I _think_ we want to have both approaches
> > (your rescan-after-white) and min_unref_count. They serve different
> > purposes. This is how I see them serving different purposes:
> > 
> > 1) This rescan-after-white proposal:
> > 
> >   Target: Developers that cat manually scanning for leaks when they
> >   develop something.
> > 
> >     a) The goal is to produce a memory leaks after the scan is done.
> >     b) Latency is more important than false positives
> >     c) min_unref_count = 1
> > 
> > 2) min_unref_count 
> > 
> >   Target: Production servers running kmemleak on some cloud "probe
> >   points", where the service will run for hours/days.
> > 
> >     a) Latency is not important (system is automatically deployed and
> >     tested)
> >     b) False positives is heavily undesirable. It causes an alarm to get
> >     some engineer to investigate.
> >     c) In this case min_unref_count will be super high (>10)
> >       - I.e, just report when you are pretty sure this is a real issue.
> >    
> > Anyway, that's what I'm seeing from my angle. Let me know if I'm way
> > off.
> 
> You are right. If you only ever use min_unref_count of 2, then the first
> option might be alright but for larger numbers, you can't just keep
> scanning 10 times in a row. If option 1 works, we might be able to get
> rid of the transient leak annotations.
> 
> I got Claude to refactor for the first idea and it mostly works. For
> some reason, after modprobe kmemleak-test, it always does the
> confirmation scan. There's an object (vmalloc) left that's reported as
> a potential leak candidate but not confirmed in the subsequent scan.
> I'll check tomorrow, need to finish the day early.

I found the issue. It was the passing of the excess_ref on the
subsequent scan. I thought I could avoid marking gray objects as white
again in the second scan but it messes up the excess_ref since they are
counted only after the object became gray. I had to add a flag,
OBJECT_SUSPECT, since we mark all objects white again for the second
pass. In principle, it's not different from your two scans approach,
only that they are done back to back.

Anyway, a better diff for the first idea below. I need to do more
testing and can turn it into a proper commit (if we don't deem it
redundant because of the other min_unref_count).

FTR, Assisted-by: Claude:claude-opus-4-8.

----------------8<----------------------------
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 7c7ba17ce7af..de16c7243847 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -175,6 +175,8 @@ struct kmemleak_object {
 #define OBJECT_PHYS		(1 << 4)
 /* flag set for per-CPU pointers */
 #define OBJECT_PERCPU		(1 << 5)
+/* flag set on an object left unreferenced by the full scan, pending confirmation */
+#define OBJECT_SUSPECT		(1 << 6)
 
 /* set when __remove_object() called */
 #define DELSTATE_REMOVED	(1 << 0)
@@ -1797,13 +1799,11 @@ static void dedup_flush(struct xarray *dedup)
  * kernel's standard allocators. This function must be called with the
  * scan_mutex held.
  */
-static void kmemleak_scan(void)
+static void __kmemleak_scan(bool full)
 {
 	struct kmemleak_object *object;
 	struct zone *zone;
 	int __maybe_unused i;
-	struct xarray dedup;
-	int new_leaks = 0;
 
 	jiffies_last_scan = jiffies;
 
@@ -1904,6 +1904,10 @@ static void kmemleak_scan(void)
 	 */
 	scan_gray_list();
 
+	/* a confirmation scan does not look for modified objects */
+	if (!full)
+		return;
+
 	/*
 	 * Check for new or unreferenced objects modified since the previous
 	 * scan and color them gray until the next scan.
@@ -1935,6 +1939,48 @@ static void kmemleak_scan(void)
 	 * Re-scan the gray list for modified unreferenced objects.
 	 */
 	scan_gray_list();
+}
+
+/*
+ * Mark the objects left unreferenced by the full scan as suspects and return
+ * true if there are any. Only suspects confirmed still unreferenced by the
+ * following scan are reported as leaks.
+ */
+static bool flag_suspects(void)
+{
+	struct kmemleak_object *object;
+	int suspects = 0;
+
+	rcu_read_lock();
+	list_for_each_entry_rcu(object, &object_list, object_list) {
+		raw_spin_lock_irq(&object->lock);
+		if (unreferenced_object(object) &&
+		    !(object->flags & OBJECT_REPORTED)) {
+			object->flags |= OBJECT_SUSPECT;
+			suspects++;
+		} else {
+			object->flags &= ~OBJECT_SUSPECT;
+		}
+		raw_spin_unlock_irq(&object->lock);
+		if (need_resched())
+			kmemleak_cond_resched(object);
+	}
+	rcu_read_unlock();
+
+	return suspects != 0;
+}
+
+/*
+ * Scan the memory and report the unreferenced objects as leaks. Must be
+ * called with the scan_mutex held.
+ */
+static void kmemleak_scan(void)
+{
+	struct kmemleak_object *object;
+	struct xarray dedup;
+	int new_leaks = 0;
+
+	__kmemleak_scan(true);
 
 	/*
 	 * If scanning was stopped do not report any new unreferenced objects.
@@ -1942,6 +1988,18 @@ static void kmemleak_scan(void)
 	if (scan_should_stop())
 		return;
 
+	/*
+	 * A live object whose only reference is moved by, for example, a
+	 * concurrent RCU update can be missed for one scan and reported as a
+	 * transient false positive. If a leak is suspected, mark again and
+	 * only report the objects left unreferenced by both scans.
+	 */
+	if (flag_suspects()) {
+		__kmemleak_scan(false);
+		if (scan_should_stop())
+			return;
+	}
+
 	/*
 	 * Scanning result reporting. When verbose printing is enabled, dedupe
 	 * by stackdepot trace_handle so each unique backtrace is logged once
@@ -1969,6 +2027,7 @@ static void kmemleak_scan(void)
 		trace_handle = 0;
 		dedup_print = false;
 		if (unreferenced_object(object) &&
+		    (object->flags & OBJECT_SUSPECT) &&
 		    !(object->flags & OBJECT_REPORTED)) {
 			object->flags |= OBJECT_REPORTED;
 			if (kmemleak_verbose) {

Re: + radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Breno Leitao]

Hello Catalin,

First of all, thanks for th
On Tue, Jul 07, 2026 at 12:19:50AM +0100, Catalin Marinas wrote:
> On Mon, Jul 06, 2026 at 05:25:25PM +0100, Catalin Marinas wrote:
> > On Mon, Jul 06, 2026 at 07:53:30AM -0700, Breno Leitao wrote:
> > > On Mon, Jul 06, 2026 at 12:39:30PM +0100, Catalin Marinas wrote:
> > > > I wonder whether we should force the scanning to happen twice in a row
> > > > and drop the min_unref_count. Those transient leaks happen because of
> > > > some micro/milliseconds miss of a pointer. If we have new white objects
> > > > of the end of a scan, go one more round through the root and gray
> > > > objects (but do not reset them to white) and only then report the leaks.
> > > > If the white objects have been reported already or we don't have any
> > > > left, skip this additional scan or bail out early. We could have a
> > > > tunable for this one to go 2-3 times if needed, though I guess twice is
> > > > sufficient. The interface is also preserved as you do an echo scan only
> > > > once (or twice initially with the checksum calculation).
> > > 
> > > That is a good proposal, and I am happy to hack it up.
> > > 
> > > On the other side, I _think_ we want to have both approaches
> > > (your rescan-after-white) and min_unref_count. They serve different
> > > purposes. This is how I see them serving different purposes:
> > > 
> > > 1) This rescan-after-white proposal:
> > > 
> > >   Target: Developers that cat manually scanning for leaks when they
> > >   develop something.
> > > 
> > >     a) The goal is to produce a memory leaks after the scan is done.
> > >     b) Latency is more important than false positives
> > >     c) min_unref_count = 1
> > > 
> > > 2) min_unref_count 
> > > 
> > >   Target: Production servers running kmemleak on some cloud "probe
> > >   points", where the service will run for hours/days.
> > > 
> > >     a) Latency is not important (system is automatically deployed and
> > >     tested)
> > >     b) False positives is heavily undesirable. It causes an alarm to get
> > >     some engineer to investigate.
> > >     c) In this case min_unref_count will be super high (>10)
> > >       - I.e, just report when you are pretty sure this is a real issue.
> > >    
> > > Anyway, that's what I'm seeing from my angle. Let me know if I'm way
> > > off.
> > 
> > You are right. If you only ever use min_unref_count of 2, then the first
> > option might be alright but for larger numbers, you can't just keep
> > scanning 10 times in a row. If option 1 works, we might be able to get
> > rid of the transient leak annotations.
> > 
> > I got Claude to refactor for the first idea and it mostly works. For
> > some reason, after modprobe kmemleak-test, it always does the
> > confirmation scan. There's an object (vmalloc) left that's reported as
> > a potential leak candidate but not confirmed in the subsequent scan.
> > I'll check tomorrow, need to finish the day early.
> 
> I found the issue. It was the passing of the excess_ref on the
> subsequent scan. I thought I could avoid marking gray objects as white
> again in the second scan but it messes up the excess_ref since they are
> counted only after the object became gray. I had to add a flag,
> OBJECT_SUSPECT, since we mark all objects white again for the second
> pass. In principle, it's not different from your two scans approach,
> only that they are done back to back.
> 
> Anyway, a better diff for the first idea below. I need to do more
> testing and can turn it into a proper commit (if we don't deem it
> redundant because of the other min_unref_count).

Thanks for it. I've reviewed it and it looks sane.

I am also testing it on my side.


> +static bool flag_suspects(void)
> +{
> +	struct kmemleak_object *object;
> +	int suspects = 0;
> +
> +	rcu_read_lock();
> +	list_for_each_entry_rcu(object, &object_list, object_list) {

__kmemleak_scan() above alread iterated over these objects. Is it
possible to piggy back on __kmemleak_scan() list_for_each_entry_rcu
forthe objects to flag SUSPECTS?

> +		raw_spin_lock_irq(&object->lock);
> +		if (unreferenced_object(object) &&
> +		    !(object->flags & OBJECT_REPORTED)) {
> +			object->flags |= OBJECT_SUSPECT;
> +			suspects++;
> +		} else {
> +			object->flags &= ~OBJECT_SUSPECT;
> +		}
> +		raw_spin_unlock_irq(&object->lock);
> +		if (need_resched())
> +			kmemleak_cond_resched(object);
> +	}
> +	rcu_read_unlock();
> +
> +	return suspects != 0;
> +}
> +
> +/*
> + * Scan the memory and report the unreferenced objects as leaks. Must be
> + * called with the scan_mutex held.
> + */
> +static void kmemleak_scan(void)
> +{
> +	struct kmemleak_object *object;
> +	struct xarray dedup;
> +	int new_leaks = 0;

It seems new_leaks and dedup are not used at all.


reviewing this code, I found that unreferenced_object(object)) is always
called/checked with (object->flags & OBJECT_REPORTED). Would it be ok to
move (object->flags & OBJECT_REPORTED) to inside unreferenced_object()?

Thanks for this work,
--breno

Re: + radix-tree-fix-kmemleak-false-positives-on-tree-head-reassignment.patch added to mm-new branch

[Catalin Marinas]

Hi Breno,

Thanks looking looking at this.

On Tue, Jul 07, 2026 at 04:26:43AM -0700, Breno Leitao wrote:
> On Tue, Jul 07, 2026 at 12:19:50AM +0100, Catalin Marinas wrote:
> > +static bool flag_suspects(void)
> > +{
> > +	struct kmemleak_object *object;
> > +	int suspects = 0;
> > +
> > +	rcu_read_lock();
> > +	list_for_each_entry_rcu(object, &object_list, object_list) {
> 
> __kmemleak_scan() above alread iterated over these objects. Is it
> possible to piggy back on __kmemleak_scan() list_for_each_entry_rcu
> for the objects to flag SUSPECTS?

That list has another scan_gray_list() afterwords. We could fold it into
the same list - flag all white objects here as suspects and clear this
flag in update_refs() if the object becomes gray. We'll probably need a
counter of suspected leaks set during this loop and decrement it during
update_refs() when an object becomes gray. Only go for a second scan if
this number is positive.

Yet another option would be for __kmemleak_scan() to return true if it
found any new candidates in this loop (new white objects that could not
be added to the gray list). It does not remove the second loop but it
makes it less likely for a system that doesn't have new leaks.

BTW, I think the flag_suspects() loop was missing an early continue if
!colour_white(), saves from taking the object look. But it still does a
list walk and I can see both loops looking pretty similar that one
wonders why they shouldn't be merged.

> > +		raw_spin_lock_irq(&object->lock);
> > +		if (unreferenced_object(object) &&
> > +		    !(object->flags & OBJECT_REPORTED)) {
> > +			object->flags |= OBJECT_SUSPECT;
> > +			suspects++;
> > +		} else {
> > +			object->flags &= ~OBJECT_SUSPECT;
> > +		}
> > +		raw_spin_unlock_irq(&object->lock);
> > +		if (need_resched())
> > +			kmemleak_cond_resched(object);
> > +	}
> > +	rcu_read_unlock();
> > +
> > +	return suspects != 0;
> > +}
> > +
> > +/*
> > + * Scan the memory and report the unreferenced objects as leaks. Must be
> > + * called with the scan_mutex held.
> > + */
> > +static void kmemleak_scan(void)
> > +{
> > +	struct kmemleak_object *object;
> > +	struct xarray dedup;
> > +	int new_leaks = 0;
> 
> It seems new_leaks and dedup are not used at all.

They are in kmemleak_scan() after the second __kmemleak_scan() call.

> reviewing this code, I found that unreferenced_object(object)) is always
> called/checked with (object->flags & OBJECT_REPORTED). Would it be ok to
> move (object->flags & OBJECT_REPORTED) to inside unreferenced_object()?

They are meant for different things. The flag is for reporting and
debugfs wants REPORTED, kmemleak_scan() checks for unreferenced and
!REPORTED,

-- 
Catalin