linux-kernel - Re: Unfair qspinlocks on ARM64 without LSE atomics => 3ms delay in interrupt handling

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: <87pm7qxrg6.ffs@tglx>
Date:   Wed, 26 Apr 2023 23:29:45 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Bouska, Zdenek" <zdenek.bouska@...mens.com>,
        Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>
Cc:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Kiszka, Jan" <jan.kiszka@...mens.com>,
        "linux-rt-users@...r.kernel.org" <linux-rt-users@...r.kernel.org>,
        Nishanth Menon <nm@...com>, Puranjay Mohan <p-mohan@...com>
Subject: Re: Unfair qspinlocks on ARM64 without LSE atomics => 3ms delay in
 interrupt handling

On Wed, Apr 26 2023 at 12:03, Zdenek Bouska wrote:
> following patch is my current approach for fixing this issue. I introduced
> big_cpu_relax(), which uses Will's implementation [1] on ARM64 without
> LSE atomics and original cpu_relax() on any other CPU.

Why is this interrupt handling specific? Just because it's the place
where you observed it?

That's a general issue for any code which uses atomics for forward
progress. LL/SC simply does not guarantee that.

So if that helps, then this needs to be addressed globaly and not with
some crude hack in the interrupt handling code.

> Anyone has a better idea how to solve this issue properly?

Use hardware with LSE atomics :)

Thanks,

        tglx