[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250514151605.9a07943954737f52e2895b05@linux-foundation.org>
Date: Wed, 14 May 2025 15:16:05 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Jared Kangas <jkangas@...hat.com>
Cc: willy@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] radix tree: fix kmemleak false positive in
radix_tree_shrink()
On Wed, 14 May 2025 11:01:37 -0700 Jared Kangas <jkangas@...hat.com> wrote:
> Kmemleak periodically produces a false positive report that resembles
> the following:
>
> unreferenced object 0xffff00000db613b8 (size 576):
> comm "systemd", pid 1, jiffies 4294987015
> hex dump (first 32 bytes):
> 00 22 01 00 00 00 00 00 28 1c d5 c5 00 00 ff ff ."......(.......
> 10 e4 6c c0 00 00 ff ff d0 13 b6 0d 00 00 ff ff ..l.............
> backtrace (crc 520d6e1c):
> kmemleak_alloc+0xb4/0xc4
> kmem_cache_alloc+0x288/0x2b0
> radix_tree_node_alloc.constprop.0+0x214/0x364
> idr_get_free+0x3d0/0x690
> idr_alloc_u32+0x120/0x280
> idr_alloc_cyclic+0xe8/0x1b4
> __kernfs_new_node+0x118/0x5a0
> kernfs_create_dir_ns+0x8c/0x1fc
> cgroup_create+0x1cc/0x8a0
> cgroup_mkdir+0x13c/0x90c
> kernfs_iop_mkdir+0x108/0x184
> vfs_mkdir+0x3c8/0x5f0
> do_mkdirat+0x218/0x290
> __arm64_sys_mkdirat+0xe0/0x140
> invoke_syscall.constprop.0+0x74/0x1e4
> do_el0_svc+0xd0/0x1dc
>
> This is a transient leak that can be traced to radix_tree_shrink(): when
> root->xa_head is set, kmemleak may have already started traversing the
> radix tree. If this has happened, but kmemleak fails to scan the new
> xa_head before it moves, kmemleak will see it as a leak until the radix
> tree is scanned again.
>
> Mark the new xa_head as a transient leak to prevent this false positive
> report.
>
> ...
>
> --- a/lib/radix-tree.c
> +++ b/lib/radix-tree.c
> @@ -509,6 +509,14 @@ static inline bool radix_tree_shrink(struct radix_tree_root *root)
> if (is_idr(root) && !tag_get(node, IDR_FREE, 0))
> root_tag_clear(root, IDR_FREE);
>
> + /*
> + * Kmemleak might report a false positive if it traverses the
> + * tree while we're shrinking it, since the reference moves
> + * from node->slots[0] to root->xa_head.
> + */
> + if (radix_tree_is_internal_node(child))
> + kmemleak_transient_leak(entry_to_node(child));
> +
There is only one other caller of kmemleak_transient_leak(). Makes me
think that perhaps a more fundamental fix is needed.
So I'll queue it for testing for now, but I won't proceed further until
some further examination has occured. Thanks.
Powered by blists - more mailing lists