linux-kernel - Re: [PATCH 3/3] locking/qspinlock: Introduce starvation avoidance into CNA

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] [day] [month] [year] [list]

Message-ID: <9ba407a6-8f16-876e-549a-d82176d2234e@redhat.com>
Date:   Tue, 5 Feb 2019 16:12:05 -0500
From:   Waiman Long <longman@...hat.com>
To:     Alex Kogan <alex.kogan@...cle.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     linux@...linux.org.uk, mingo@...hat.com, will.deacon@....com,
        arnd@...db.de, linux-arch@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Steven Sistare <steven.sistare@...cle.com>,
        Daniel Jordan <daniel.m.jordan@...cle.com>,
        dave.dice@...cle.com, Rahul Yadav <rahul.x.yadav@...cle.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 3/3] locking/qspinlock: Introduce starvation avoidance
 into CNA

On 02/05/2019 04:07 PM, Alex Kogan wrote:
>> Doing time analysis on a randomized algorithm isn't my idea of fun.
>>
>>> It seems that even today, qspinlock does not support RT_PREEMPT, given
>>> that it uses per-CPU queue nodes.
>> It does work with RT, commit:
>>
>>  7aa54be29765 ("locking/qspinlock, x86: Provide liveness guarantee")
>>
>> it a direct result of RT observing funnies with it. I've no idea why you
>> think it would not work.
> Just trying to get to the bottom of it — as of today, qspinlock explicitly assumes
> no preemption while waiting for the lock.
>
> Here is what Waiman had to say about that in https://lwn.net/Articles/561775:
>
> "The idea behind this spinlock implementation is the fact that spinlocks
> are acquired with preemption disabled. In other words, the process
> will not be migrated to another CPU while it is trying to get a
> spinlock.”
>
> This was back in 2013, but the code still uses per-CPU queue nodes,
> and AFAICT, preemption will break things up.
>
> So what you are saying is that RT would be fine assuming no preemption in
> the spinlock as long as it provides FIFO? Or there is some future code patch 
> that will take care of the “no preemption” assumption (but still assume FIFO)?
>
> Thanks,
> — Alex

Some of the critical sections protected by spinlocks may have execution
times that are much longer than desired. That is why they are converted
to rt-mutex in the RT kernel. There is another class of spinlocks called
raw spinlocks. They are the same as regular spinlocks in non RT-kernel,
but remain spinlocks with no preemption allowed in RT-kernel as sleeping
locks can't be used in atomic context. This is where the replacement of
the current qspinlock code by your NUMA-aware qspinlock may screw up the
timing guarantee that can be provided by the RT-kernel.

Cheers,
Longman