[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bbb0959d-5ad1-846b-b896-eb4c5dd900bf@bytedance.com>
Date: Fri, 8 Sep 2023 17:47:03 +0800
From: Peng Zhang <zhangpeng.00@...edance.com>
To: Matthew Wilcox <willy@...radead.org>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Peng Zhang <zhangpeng.00@...edance.com>,
kernel test robot <oliver.sang@...el.com>,
oe-lkp@...ts.linux.dev, lkp@...el.com,
maple-tree@...ts.infradead.org, linux-mm@...ck.org, corbet@....net,
akpm@...ux-foundation.org, brauner@...nel.org, surenb@...gle.com,
michael.christie@...cle.com, peterz@...radead.org,
mathieu.desnoyers@...icios.com, npiggin@...il.com,
avagin@...il.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2 5/6] maple_tree: Update check_forking() and
bench_forking()
在 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.
>
Powered by blists - more mailing lists