[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mtp21wqr.ffs@tglx>
Date: Fri, 27 Aug 2021 22:03:08 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Boqun Feng <boqun.feng@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Juri Lelli <juri.lelli@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Davidlohr Bueso <dave@...olabs.net>,
Mike Galbraith <efault@....de>
Subject: Re: [patch V5 32/72] locking/rtmutex: Provide the spin/rwlock core
lock function
On Sat, Aug 28 2021 at 01:21, Boqun Feng wrote:
> On Sun, Aug 15, 2021 at 11:28:25PM +0200, Thomas Gleixner wrote:
>> From: Thomas Gleixner <tglx@...utronix.de>
>> +static __always_inline void __sched rtlock_slowlock(struct rt_mutex_base *lock)
>> +{
>> + unsigned long flags;
>> +
>> + raw_spin_lock_irqsave(&lock->wait_lock, flags);
>> + rtlock_slowlock_locked(lock);
>> + raw_spin_unlock_irqrestore(&lock->wait_lock, flags);
>
> Just out of curiosity, could we use raw_spin_{un,}lock_irq() here
> instead of *_irq{save,restore}()? Because rtlock_slowlock() might sleep,
> and we cannot call it with irq-off.
Unfortunately we can during early boot when lock debugging is enabled
because then the fast path is disabled. We might make it conditional on
!DEBUG though, but I'm not sure whether it's worth it.
Thanks,
tglx
Powered by blists - more mailing lists