Re: [PATCH v2 5/6] maple_tree: Update check_forking() and bench_forking()

[Peng Zhang]

在 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.