On 9/3/24 20:36, Liam R. Howlett wrote:
- Guenter Roeck linux@roeck-us.net [240903 22:38]:
On 9/3/24 19:31, Liam R. Howlett wrote:
- SeongJae Park sj@kernel.org [240903 21:18]:
On Tue, 3 Sep 2024 17:58:15 -0700 SeongJae Park sj@kernel.org wrote:
On Tue, 3 Sep 2024 20:48:53 -0400 "Liam R. Howlett" Liam.Howlett@oracle.com wrote:
- SeongJae Park sj@kernel.org [240903 20:45]:
> damon_test_three_regions_in_vmas() initializes a maple tree with > MM_MT_FLAGS. The flags contains MT_FLAGS_LOCK_EXTERN, which means > mt_lock of the maple tree will not be used. And therefore the maple > tree initialization code skips initialization of the mt_lock. However, > __link_vmas(), which adds vmas for test to the maple tree, uses the > mt_lock. In other words, the uninitialized spinlock is used. The > problem becomes celar when spinlock debugging is turned on, since it > reports spinlock bad magic bug. Fix the issue by not using the mt_lock > as promised.
You can't do this, lockdep will tell you this is wrong.
Hmm, but lockdep was silence on my setup?
We need a lock and to use the lock for writes.
This code is executed by a single-thread test code. Do we still need the lock?
I'd suggest using different flags so the spinlock is used.
The reporter mentioned simply dropping MT_FLAGS_LOCK_EXTERN from the flags causes suspicious RCU usage message. May I ask if you have a suggestion of better flags?
That would be the lockdep complaining, so that's good.
I was actually thinking replacing the mt_init_flags() with mt_init(), which same to mt_init_flags() with zero flag, like below.
Yes. This will use the spinlock which should fix your issue, but it will use a different style of maple tree.
Perhaps use MT_FLAGS_ALLOC_RANGE to use the same type of maple tree, if you ever add threading you will want the rcu flag as well (MT_FLAGS_USE_RCU).
I would recommend those two and just use the spinlock.
I tried that (MT_FLAGS_ALLOC_RANGE | MT_FLAGS_USE_RCU). it also triggers the suspicious RCU usage message.
I am running ./tools/testing/kunit/kunit.py run '*damon*' --arch x86_64 --raw with: CONFIG_LOCKDEP=y CONFIG_DEBUG_SPINLOCK=y
and I don't have any issue with locking in the existing code. How do I recreate this issue?
You should find everything needed to reproduce the problem at http://server.roeck-us.net/qemu/damon/
Please let me know if you need anything else.
Thanks, Guenter