lkml.org 
[lkml]   [2019]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.


\
 
 \ /
  Last update: 2019-02-01 13:16    [W:0.119 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site