Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Waiman Long <llong@redhat.com>
Subject: Re: [PATCH 1/2] locking/mutex: remove rcu_read_lock/unlock as we
 already disabled preemption
To:     Yanfei Xu <yanfei.xu@windriver.com>, peterz@infradead.org,
        mingo@redhat.com, will@kernel.org, boqun.feng@gmail.com
Cc:     linux-kernel@vger.kernel.org
References: <20210926101624.2460704-1-yanfei.xu@windriver.com>
 <9569eee4-266f-d83b-2af6-194a1a8b165c@redhat.com>
Message-ID: <70424003-1b4a-bb92-1123-7820d6321717@redhat.com>
Date:   Sun, 26 Sep 2021 20:46:59 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <9569eee4-266f-d83b-2af6-194a1a8b165c@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

On 9/26/21 3:16 PM, Waiman Long wrote:
> 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. 

It does look like that disable preemption can serve as a substitute for 
rcu_read_lock(). However, I will suggest that you also insert a comment 
saying so and the task structure won't go away during the spinning period.

Cheers,
Longman