Lines Matching refs:this

11 overwriting or worse.  There can of course be false positives, this
22 other info that might help us debug this:
68 section, but the "other info" list above shows that this is not the
70 And maybe that lock really does protect this reference.  If so, the fix
78 With this change, there would be no lockdep-RCU splat emitted if this
80 or with the ->queue_lock held.  In particular, this would have suppressed
85 section.  In this case, the critical section must span the use of the
87 reference count incremented or some such.  One way to handle this is to
98 With this change, the rcu_dereference() is always within an RCU
102 But in this particular case, we don't actually deference the pointer
110 this change would also suppress the above lockdep-RCU splat.