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:   Thomas Gleixner <tglx@linutronix.de>
To:     Hillf Danton <hdanton@sina.com>
Cc:     LKML <linux-kernel@vger.kernel.org>
Subject: Re: [patch 30/63] locking/spinlock: Provide RT variant
In-Reply-To: <20210803063217.2325-1-hdanton@sina.com>
References: <20210730135007.155909613@linutronix.de>
 <20210803063217.2325-1-hdanton@sina.com>
Date:   Tue, 03 Aug 2021 11:10:48 +0200
Message-ID: <874kc6rizr.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Tue, Aug 03 2021 at 14:32, Hillf Danton wrote:
> On Fri, 30 Jul 2021 15:50:37 +0200
>> + *   The RT substitutions explicitly disable migration and take
>> + *   rcu_read_lock() across the lock held section.
>> + */
>
> My stupid question is how it works in scenarios like spinlock chain
>
> 	spin_lock(&foo->lock);
> 	spin_lock(&bar->lock);
> 	do something for foo and bar;
> 	spin_unlock(&bar->lock);
> 	spin_unlock(&foo->lock);
>
> with rcu read lock held across the lock protected section because rcu
> lock has preempt disabled and that will disallow scheduling while acquiring
> the inner lock.

If CONFIG_PREEMPT_RCU=y rcu_read_lock() does not disable
preemption. This is even true for !RT kernels with CONFIG_PREEMPT=y

Thanks,

        tglx