linux-kernel - Re: [PATCH 1/2] locking/mutex: remove rcu_read_lock/unlock as we already disabled preemption

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]

Message-ID: <9569eee4-266f-d83b-2af6-194a1a8b165c@redhat.com>
Date:   Sun, 26 Sep 2021 15:16:48 -0400
From:   Waiman Long <llong@...hat.com>
To:     Yanfei Xu <yanfei.xu@...driver.com>, peterz@...radead.org,
        mingo@...hat.com, will@...nel.org, boqun.feng@...il.com
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] locking/mutex: remove rcu_read_lock/unlock as we
 already disabled preemption

On 9/26/21 6:16 AM, Yanfei Xu wrote:
> preempt_disable/enable() is equal to RCU read-side crital section,
> and the mutex lock slowpath disable the preemption throughout the
> entire slowpath. Let's remove the rcu_read_lock/unlock for saving
> some cycles in hot codes.

The description is wrong. Preemption is disabled only in the optimistic 
spinning code which is not the complete slowpath. Even though it may 
sound reasonable that disable preemption is likely to prevent reaching 
quiescent state, but I am not totally sure that will always be the case 
as there are different RCU favors.

Cheers,
Longman