在 2023/9/8 02:16, Matthew Wilcox 写道:
On Thu, Sep 07, 2023 at 02:03:01PM -0400, Liam R. Howlett wrote:
WARNING: possible recursive locking detected
6.5.0-rc4-00632-g2730245bd6b1 #1 Tainted: G TN
--------------------------------------------
swapper/1 is trying to acquire lock:
ffffffff86485058 (&mt->ma_lock){+.+.}-{2:2}, at: check_forking (include/linux/spinlock.h:? lib/test_maple_tree.c:1854)
but task is already holding lock:
ffff888110847a30 (&mt->ma_lock){+.+.}-{2:2}, at: check_forking (include/linux/spinlock.h:351 lib/test_maple_tree.c:1854)
Thanks for the test. I checked that these are two different locks, why
is this warning reported? Did I miss something?
I don't think you can nest spinlocks like this. In my previous test I
avoided nesting, but in your case we cannot avoid having both locks at
the same time.
You can get around this by using an rwsemaphore, set the two trees as
external and use down_write_nested(&lock2, SINGLE_DEPTH_NESTING) like
the real fork. Basically, switch the locking to exactly what fork does.
Here I can use rwsemaphore to avoid the warning. But what about in
mtree_dup()? mtree_dup() handles locks internally.
Maybe spin_lock_nested() mentioned by Matthew can be used in
mtree_dup().
spin_lock_nested() exists.
Thanks for mentioning this, I'll have a look.
You should probably both read through
Documentation/locking/lockdep-design.rst It's not the best user
documentation in the world, but it's what we have.
