Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Tejun Heo <htejun@gmail.com>
Date:   Sun, 12 Jun 2022 17:09:33 -1000
From:   Tejun Heo <tj@kernel.org>
To:     Imran Khan <imran.f.khan@oracle.com>
Cc:     viro@zeniv.linux.org.uk, gregkh@linuxfoundation.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND v4 1/4] kernfs: make ->attr.open RCU protected.
Message-ID: <Yqaqbas1JaWz25jB@slm.duckdns.org>
References: <20220602063907.136569-1-imran.f.khan@oracle.com>
 <20220602063907.136569-2-imran.f.khan@oracle.com>
 <YqYpTShTDLvAp4vx@slm.duckdns.org>
 <6d1c5a49-fc16-5fc7-e527-8cb91ec0d25c@oracle.com>
 <YqalHuEB6OjjUosV@slm.duckdns.org>
 <c8a8a616-da4c-f2ce-0bb2-e0cba69db24d@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <c8a8a616-da4c-f2ce-0bb2-e0cba69db24d@oracle.com>
Precedence: bulk

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