Messages in this thread | | | Date | Wed, 17 Mar 2021 17:48:48 +0100 | From | Peter Zijlstra <> | Subject | Re: [tip: locking/urgent] locking/ww_mutex: Treat ww_mutex_lock() like a trylock |
| |
On Wed, Mar 17, 2021 at 11:35:12AM -0400, Waiman Long wrote:
> From reading the source code, nest_lock check is done in check_deadlock() so > that it won't complain. However, nest_lock isn't considered in > check_noncircular() which causes the splat to come out. Maybe we should add > a check for nest_lock there. I will fiddle with the code to see if it can > address the issue.
Nah, that's not how it's supposed to work. I think the problem is that DEFINE_WW_MUTEX is buggered, there's not actually any other user of it in-tree.
Everybody else (including locking-selftests) seem to be using ww_mutex_init().
So all locks in a ww_class should be having the same lock class, and then nest_lock will fold them all into a single entry with ->references incremented. See __lock_acquire().
But from the report:
> [ 103.892671] -> #2 (torture_ww_mutex_0.base){+.+.}-{3:3}: > [ 103.892706] -> #1 (torture_ww_mutex_1.base){+.+.}-{3:3}: > [ 103.892730] -> #0 (torture_ww_mutex_2.base){+.+.}-{3:3}:
that went sideways, they're *not* the same class.
I think you'll find that if you use ww_mutex_init() it'll all work. Let me go and zap this patch, and then I'll try and figure out why DEFINE_WW_MUTEX() is buggered.
| |