Messages in this thread | | | Date | Fri, 1 Feb 2019 13:15:10 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH v6 00/16] locking/lockdep: Add support for dynamic keys |
| |
On Fri, Jan 18, 2019 at 06:34:20PM -0800, Bart Van Assche wrote:
> I agree with what you wrote. The only code I know of that accesses list > entries using RCU is the __bfs() function. In that function I found the > following loop: > > list_for_each_entry_rcu(entry, head, entry) { [ ... ] }
Thing is; I can't seem to find any __bfs() usage outside of graph_lock.
count_{fwd,bwd}_deps() - takes graph lock
check_{noncircular,redudant}() - called from check_prev_add() <- check_prevs_add() <- validate_chain() which takes graph lock
find_usage{,_fwd,_bwd} <- check_usage() <- check_irq_usage() <- check_prev_add_irq() <- check_prev_add <- check_prevs_add() <- validate_chain() which takes graph lock
<- check_usage_{fwd,bdw}() <- mark_lock_irq() <- mark_lock() which takes graph lock
Or did I miss something? If there are no __bfs() users outside of graph lock, then we can simply remove that _rcu from the iteration, and simplify all that.
> Since zap_class() calls list_del_rcu(&entry->entry), since a grace period > occurs between the call_rcu() invocation and the RCU callback function, > since at least an RCU reader lock must be held around RCU loops and since > sleeping is not allowed while holding an RCU read lock I think there is > no risk that __bfs() will examine a list entry after it has been freed.
So you agree that list_entry_being_freed() should only check the current pf?
Also; yes, I seem to have completely misplaced your #14, I've not idea how I totally lost one patch, that was certainly not intentional, sorry about that.
| |