lockdep: (Was: check && lockdep_no_validate)
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest5 patches 14 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/5 | lockdep: make held_lock->check and "int check" argument booldrivers/ include/ include/ +1 more | +18 | 0 replies | |
| 2/5 | lockdep: don't create the wrong dependency on hlock->check == 0kernel/ | +2 | 0 replies | |
| 3/5 | lockdep: change mark_held_locks() to check hlock->check instead of lockdep_no_validatekernel/ | +1 | 0 replies | |
| 4/5 | lockdep: change lockdep_set_novalidate_class() to use _and_nameinclude/ | +1 | 0 replies | |
| 5/5 | lockdep: pack subclass/trylock/read/check into a single argumentinclude/ kernel/ | +39 | 11 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/5] lockdep: (Was: check && lockdep_no_validate)
Quoted 8 lines · Alan Stern
Quoted 4 lines · Oleg Nesterov
Yes, sure. This change assumes that the only problem in
drivers/baseisdev->parent->mutex/dev->mutexdependency. If the locking is even more "broken" (wrt lockdep), we can't replacelockdep_set_novalidate_class()withlockdep_set_auto_nested().
Quoted 7 lines
I suspect it is even more "broken". But I can't point to specific examples.
...
My guess is that if your change is deployed widely, there will be reports of violations. That's only a guess.
OK, lets (try to) do this later. Let me send the changes which I hope should be fine in any case.
Quoted 1 line
Still, you could go ahead and try it, just to see what happens.
Yes, perhaps it makes sense at least to test this change and see what happens... We will see.
Quoted 2 lines
Also, take a look at commit
356c05d58af0. It's a similar situation (not exactly the same).
At first glance, can't __ATTR_IGNORE_LOCKDEP() use no_validate too ? (ignoring the fact checkpatch.pl won't be happy). This can simplify the code, it seems.
Oleg.