linux-kernel - Re: [PATCH] rust: maple_tree: rcu_read_lock() in destructor to silence lockdep

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aUMRU0yKwQVDuUnZ@google.com>
Date: Wed, 17 Dec 2025 20:23:47 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>, Matthew Wilcox <willy@...radead.org>, 
	Andrew Ballance <andrewjballance@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	"Björn Roy Baron" <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, maple-tree@...ts.infradead.org, linux-mm@...ck.org, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org, 
	stable@...r.kernel.org
Subject: Re: [PATCH] rust: maple_tree: rcu_read_lock() in destructor to
 silence lockdep

On Wed, Dec 17, 2025 at 02:49:18PM -0500, Liam R. Howlett wrote:
> * Alice Ryhl <aliceryhl@...gle.com> [251217 08:10]:
> > When running the Rust maple tree kunit tests with lockdep, you may
> > trigger a warning that looks like this:
> > 
> > 	lib/maple_tree.c:780 suspicious rcu_dereference_check() usage!
> > 
> > 	other info that might help us debug this:
> > 
> > 	rcu_scheduler_active = 2, debug_locks = 1
> > 	no locks held by kunit_try_catch/344.
> > 
> > 	stack backtrace:
> > 	CPU: 3 UID: 0 PID: 344 Comm: kunit_try_catch Tainted: G                 N  6.19.0-rc1+ #2 NONE
> > 	Tainted: [N]=TEST
> > 	Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
> > 	Call Trace:
> > 	 <TASK>
> > 	 dump_stack_lvl+0x71/0x90
> > 	 lockdep_rcu_suspicious+0x150/0x190
> > 	 mas_start+0x104/0x150
> > 	 mas_find+0x179/0x240
> > 	 _RINvNtCs5QSdWC790r4_4core3ptr13drop_in_placeINtNtCs1cdwasc6FUb_6kernel10maple_tree9MapleTreeINtNtNtBL_5alloc4kbox3BoxlNtNtB1x_9allocator7KmallocEEECsgxAQYCfdR72_25doctests_kernel_generated+0xaf/0x130
> > 	 rust_doctest_kernel_maple_tree_rs_0+0x600/0x6b0
> > 	 ? lock_release+0xeb/0x2a0
> > 	 ? kunit_try_catch_run+0x210/0x210
> > 	 kunit_try_run_case+0x74/0x160
> > 	 ? kunit_try_catch_run+0x210/0x210
> > 	 kunit_generic_run_threadfn_adapter+0x12/0x30
> > 	 kthread+0x21c/0x230
> > 	 ? __do_trace_sched_kthread_stop_ret+0x40/0x40
> > 	 ret_from_fork+0x16c/0x270
> > 	 ? __do_trace_sched_kthread_stop_ret+0x40/0x40
> > 	 ret_from_fork_asm+0x11/0x20
> > 	 </TASK>
> > 
> > This is because the destructor of maple tree calls mas_find() without
> 
> The wording of "destructor of maple tree" makes it sound like the tree
> itself is being destroyed, but this is to do with the stored entries
> being destroyed, correct?

Yes, it's the destructor of the Rust MapleTree<T>, which performs a
mas_find() loop to drop each Rust value before it calls mtree_destroy().

> > taking rcu_read_lock() or the spinlock. Doing that is actually ok in
> > this case since the destructor has exclusive access to the entire maple
> > tree, but it triggers a lockdep warning. To fix that, take the rcu read
> > lock.
> > 
> > In the future, it's possible that memory reclaim could gain a feature
> > where it reallocates entries in maple trees even if no user-code is
> > touching it. If that feature is added, then this use of rcu read lock
> > would become load-bearing, so I did not make it conditional on lockdep.
> > 
> > We have to repeatedly take and release rcu because the destructor of T
> > might perform operations that sleep.
> 
> The c side avoids handling the life cycle of the entries because we
> really don't know what is required.  Maybe it would be better to let the
> person storing the data handle the freeing of the entries (and thus the
> locking)?

The general expectation is that dropping a container also drops anything
contained within it. It would be very surprising for a data structure to
violate that in Rust.

The end-user is always welcome to use a type with no destructor if they
don't want the mas_find() loop.

Alice