Messages in this thread | | | Date | Sun, 12 Jun 2022 17:09:33 -1000 | From | Tejun Heo <> | Subject | Re: [PATCH RESEND v4 1/4] kernfs: make ->attr.open RCU protected. |
| |
On Mon, Jun 13, 2022 at 12:55:14PM +1000, Imran Khan wrote: > I took below phrases as reference: > > If the access might be within an RCU read-side critical section on the one hand, > or protected by (say) my_lock on the other, use rcu_dereference_check(), for > example: > > p1 = rcu_dereference_check(p->rcu_protected_pointer, > lockdep_is_held(&my_lock)); > > > and > > > If the access might be within an RCU read-side critical section on the one hand, > or protected by either my_lock or your_lock on the other, again use > rcu_dereference_check(), for example: > > p1 = rcu_dereference_check(p->rcu_protected_pointer, > lockdep_is_held(&my_lock) || > lockdep_is_held(&your_lock));
So, both are saying that if a given reference can be under both read critical section or a lock which blocks updates, you can use deref_check to cover both cases - we're just using the stronger form of derefing even though that's not necessary while update side is locked out, which is fine.
The protected one is different in that it doesn't enforce the load ordering which is required for accesses with only RCU read lock. Given that all that's required is dependency ordering, I doubt it makes any actual difference and it likely is more useful in marking a specific dereference as always being with the update side locked.
tl;dr is that you're way over-thinking the rcu deref code. Just make one deref accessor which encompasses all three use cases.
Thanks.
-- tejun
| |