* Re: [PATCH] rust: maple_tree: rcu_read_lock() in destructor to silence lockdep
2025-12-17 13:10 [PATCH] rust: maple_tree: rcu_read_lock() in destructor to silence lockdep Alice Ryhl
@ 2025-12-17 13:49 ` Gary Guo
2025-12-17 14:11 ` Daniel Almeida
2025-12-17 19:49 ` Liam R. Howlett
2 siblings, 0 replies; 5+ messages in thread
From: Gary Guo @ 2025-12-17 13:49 UTC (permalink / raw)
To: Alice Ryhl
Cc: Matthew Wilcox, Liam R. Howlett, Andrew Ballance, Andrew Morton,
Miguel Ojeda, Boqun Feng, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Danilo Krummrich, maple-tree,
linux-mm, rust-for-linux, linux-kernel, stable
On Wed, 17 Dec 2025 13:10:37 +0000
Alice Ryhl <aliceryhl@google.com> wrote:
> 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
> 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.
>
> Reported-by: Andreas Hindborg <a.hindborg@kernel.org>
> Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/564215108
> Fixes: da939ef4c494 ("rust: maple_tree: add MapleTree")
> Cc: stable@vger.kernel.org
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Intended for the same tree as any other maple tree patch. (I believe
> that's Andrew Morton's tree.)
> ---
> rust/kernel/maple_tree.rs | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/rust/kernel/maple_tree.rs b/rust/kernel/maple_tree.rs
> index e72eec56bf5772ada09239f47748cd649212d8b0..265d6396a78a17886c8b5a3ebe7ba39ccc354add 100644
> --- a/rust/kernel/maple_tree.rs
> +++ b/rust/kernel/maple_tree.rs
> @@ -265,7 +265,16 @@ unsafe fn free_all_entries(self: Pin<&mut Self>) {
> loop {
> // This uses the raw accessor because we're destroying pointers without removing them
> // from the maple tree, which is only valid because this is the destructor.
> - let ptr = ma_state.mas_find_raw(usize::MAX);
> + //
> + // Take the rcu lock because mas_find_raw() requires that you hold either the spinlock
> + // or the rcu read lock. This is only really required if memory reclaim might
> + // reallocate entries in the tree, as we otherwise have exclusive access. That feature
> + // doesn't exist yet, so for now, taking the rcu lock only serves the purpose of
> + // silencing lockdep.
> + let ptr = {
> + let _rcu = kernel::sync::rcu::Guard::new();
> + ma_state.mas_find_raw(usize::MAX)
> + };
> if ptr.is_null() {
> break;
> }
>
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20251217-maple-drop-rcu-dfe72fb5f49e
>
> Best regards,
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] rust: maple_tree: rcu_read_lock() in destructor to silence lockdep
2025-12-17 13:10 [PATCH] rust: maple_tree: rcu_read_lock() in destructor to silence lockdep Alice Ryhl
2025-12-17 13:49 ` Gary Guo
@ 2025-12-17 14:11 ` Daniel Almeida
2025-12-17 19:49 ` Liam R. Howlett
2 siblings, 0 replies; 5+ messages in thread
From: Daniel Almeida @ 2025-12-17 14:11 UTC (permalink / raw)
To: Alice Ryhl
Cc: Matthew Wilcox, Liam R. Howlett, Andrew Ballance, Andrew Morton,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
maple-tree, linux-mm, rust-for-linux, linux-kernel, stable
> On 17 Dec 2025, at 10:10, Alice Ryhl <aliceryhl@google.com> wrote:
>
> 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
> 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.
>
> Reported-by: Andreas Hindborg <a.hindborg@kernel.org>
> Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/564215108
> Fixes: da939ef4c494 ("rust: maple_tree: add MapleTree")
> Cc: stable@vger.kernel.org
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> Intended for the same tree as any other maple tree patch. (I believe
> that's Andrew Morton's tree.)
> ---
> rust/kernel/maple_tree.rs | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/rust/kernel/maple_tree.rs b/rust/kernel/maple_tree.rs
> index e72eec56bf5772ada09239f47748cd649212d8b0..265d6396a78a17886c8b5a3ebe7ba39ccc354add 100644
> --- a/rust/kernel/maple_tree.rs
> +++ b/rust/kernel/maple_tree.rs
> @@ -265,7 +265,16 @@ unsafe fn free_all_entries(self: Pin<&mut Self>) {
> loop {
> // This uses the raw accessor because we're destroying pointers without removing them
> // from the maple tree, which is only valid because this is the destructor.
> - let ptr = ma_state.mas_find_raw(usize::MAX);
> + //
> + // Take the rcu lock because mas_find_raw() requires that you hold either the spinlock
> + // or the rcu read lock. This is only really required if memory reclaim might
> + // reallocate entries in the tree, as we otherwise have exclusive access. That feature
> + // doesn't exist yet, so for now, taking the rcu lock only serves the purpose of
> + // silencing lockdep.
> + let ptr = {
> + let _rcu = kernel::sync::rcu::Guard::new();
> + ma_state.mas_find_raw(usize::MAX)
> + };
> if ptr.is_null() {
> break;
> }
>
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20251217-maple-drop-rcu-dfe72fb5f49e
>
> Best regards,
> --
> Alice Ryhl <aliceryhl@google.com>
>
>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] rust: maple_tree: rcu_read_lock() in destructor to silence lockdep
2025-12-17 13:10 [PATCH] rust: maple_tree: rcu_read_lock() in destructor to silence lockdep Alice Ryhl
2025-12-17 13:49 ` Gary Guo
2025-12-17 14:11 ` Daniel Almeida
@ 2025-12-17 19:49 ` Liam R. Howlett
2025-12-17 20:23 ` Alice Ryhl
2 siblings, 1 reply; 5+ messages in thread
From: Liam R. Howlett @ 2025-12-17 19:49 UTC (permalink / raw)
To: Alice Ryhl
Cc: Matthew Wilcox, Andrew Ballance, Andrew Morton, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Danilo Krummrich, maple-tree,
linux-mm, rust-for-linux, linux-kernel, stable
* Alice Ryhl <aliceryhl@google.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?
> 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)?
>
> Reported-by: Andreas Hindborg <a.hindborg@kernel.org>
> Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/564215108
> Fixes: da939ef4c494 ("rust: maple_tree: add MapleTree")
> Cc: stable@vger.kernel.org
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> Intended for the same tree as any other maple tree patch. (I believe
> that's Andrew Morton's tree.)
> ---
> rust/kernel/maple_tree.rs | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/rust/kernel/maple_tree.rs b/rust/kernel/maple_tree.rs
> index e72eec56bf5772ada09239f47748cd649212d8b0..265d6396a78a17886c8b5a3ebe7ba39ccc354add 100644
> --- a/rust/kernel/maple_tree.rs
> +++ b/rust/kernel/maple_tree.rs
> @@ -265,7 +265,16 @@ unsafe fn free_all_entries(self: Pin<&mut Self>) {
> loop {
> // This uses the raw accessor because we're destroying pointers without removing them
> // from the maple tree, which is only valid because this is the destructor.
> - let ptr = ma_state.mas_find_raw(usize::MAX);
> + //
> + // Take the rcu lock because mas_find_raw() requires that you hold either the spinlock
> + // or the rcu read lock. This is only really required if memory reclaim might
> + // reallocate entries in the tree, as we otherwise have exclusive access. That feature
> + // doesn't exist yet, so for now, taking the rcu lock only serves the purpose of
> + // silencing lockdep.
> + let ptr = {
> + let _rcu = kernel::sync::rcu::Guard::new();
> + ma_state.mas_find_raw(usize::MAX)
> + };
> if ptr.is_null() {
> break;
> }
>
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20251217-maple-drop-rcu-dfe72fb5f49e
>
> Best regards,
> --
> Alice Ryhl <aliceryhl@google.com>
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] rust: maple_tree: rcu_read_lock() in destructor to silence lockdep
2025-12-17 19:49 ` Liam R. Howlett
@ 2025-12-17 20:23 ` Alice Ryhl
0 siblings, 0 replies; 5+ messages in thread
From: Alice Ryhl @ 2025-12-17 20:23 UTC (permalink / raw)
To: Liam R. Howlett, Matthew Wilcox, Andrew Ballance, Andrew Morton,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
maple-tree, linux-mm, rust-for-linux, linux-kernel, stable
On Wed, Dec 17, 2025 at 02:49:18PM -0500, Liam R. Howlett wrote:
> * Alice Ryhl <aliceryhl@google.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
^ permalink raw reply [flat|nested] 5+ messages in thread