linux-kernel - Re: [PATCH RESEND v4 1/4] kernfs: make ->attr.open RCU protected.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 12 Jun 2022 17:09:33 -1000
From:   Tejun Heo <tj@...nel.org>
To:     Imran Khan <imran.f.khan@...cle.com>
Cc:     viro@...iv.linux.org.uk, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org
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