linux-kernel - Re: [PATCH V2] x86/split_lock: Add sysctl to control the misery mode

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]

Date:   Fri, 14 Oct 2022 21:19:11 -0300
From:   "Guilherme G. Piccoli" <gpiccoli@...lia.com>
To:     "Luck, Tony" <tony.luck@...el.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Cc:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "Lutomirski, Andy" <luto@...nel.org>,
        "corbet@....net" <corbet@....net>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "kernel-dev@...lia.com" <kernel-dev@...lia.com>,
        "kernel@...ccoli.net" <kernel@...ccoli.net>,
        Andre Almeida <andrealmeid@...lia.com>,
        "Yu, Fenghua" <fenghua.yu@...el.com>,
        Joshua Ashton <joshua@...ggi.es>,
        Melissa Wen <mwen@...lia.com>,
        Paul Gofman <pgofman@...eweavers.com>,
        Pavel Machek <pavel@...x.de>,
        Pierre-Loup Griffais <pgriffais@...vesoftware.com>,
        Zebediah Figura <zfigura@...eweavers.com>
Subject: Re: [PATCH V2] x86/split_lock: Add sysctl to control the misery mode

On 14/10/2022 15:26, Luck, Tony wrote:
> Looks reasonable.
> 
> Are these games multi-threaded with split locks happening on multiple CPUs in parallel?
> If they are, then skipping both the 10ms delay and the serialization is needed.
> 
> But if split locks are only from one CPU at a time, then possibly it would have
> been enough to just have this mitigation skip the:
> 
> +		if (msleep_interruptible(10) > 0)
> +			return;
> 
> Maybe best not to second guess. You have left the default as "mitigation on",
> so I'm happy.
> 
> -Tony

Hi Tony, thanks for your review!

Some games are indeed multi-threaded, so as you said, I think it's
better if we skip the whole thing when the sysctl is off - a kind of
fallback to the old "warn" mode before the misery was added heh

Cheers,


Guilherme