public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>
Cc: "mingo@redhat.com" <mingo@redhat.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"Lutomirski, Andy" <luto@kernel.org>,
	"kernel-dev@igalia.com" <kernel-dev@igalia.com>,
	"kernel@gpiccoli.net" <kernel@gpiccoli.net>,
	"Yu, Fenghua" <fenghua.yu@intel.com>,
	Joshua Ashton <joshua@froggi.es>,
	Paul Gofman <pgofman@codeweavers.com>,
	Pavel Machek <pavel@denx.de>,
	Pierre-Loup Griffais <pgriffais@valvesoftware.com>,
	Melissa Wen <mwen@igalia.com>
Subject: Re: [PATCH] x86/split_lock: Restore warn mode (and add a new one) to avoid userspace regression
Date: Thu, 06 Oct 2022 22:15:24 +0200	[thread overview]
Message-ID: <87pmf4bter.ffs@tglx> (raw)
In-Reply-To: <9d9d2d5c-1b7a-721b-f0e2-f591bb170723@igalia.com>

On Wed, Sep 28 2022 at 17:56, Guilherme G. Piccoli wrote:
> On 28/09/2022 17:24, Luck, Tony wrote:
>> [...] 
>> Why not just use the workaround suggested in that bug report:
>> 
>>    "so manual switching from default setting to split_lock_detect=off helps as workaround here"
>> 
>> If you add this extra mode, I'm going to argue that the kernel default
>> should be "seq" rather than "warn". So these game players will need
>> to add a split_lock_detect=off (or warn) option.
>> 
>
> Hi Tony, thanks for your response. The workaround is the way to
> circumvent the issue for now, but not all users want (or know how) to
> deal with the kernel parameters. If a distro wants to default to show a
> warning only, but don't break performance so hard, this would be
> currently impossible.

That Kconfig knob is patently bad. The only sane choice for a generic
distro kernel is to slow down the offenders simply because split lock is
a trivial unpriviledged DoS. Run a split locker in a tight loop and
watch your shiny new multicore system degrading into a machine from the
80s. So unless the distro provides a "special broken games" kernel the
users will still need to fiddle with the command line.

Attack vector prevention has precedence over broken applications. That's what
command line options or sysctls are for.

> The main/big issues here are two: defaulting to the disruptive behavior
> (with no way of building a kernel not defaulting to that without
> patching), and not having a way to warn about split locking without
> breaking the performance, hence the new mode "seq".

Which is a misnomer and tells absolutely nothing. If we add a new
parameter then we name it something like "mitigate" and make it the
default.

But a way better solution is to add a sysctl knob which allows to
disable the slowdown mechanics and that allows distros to give the user
an trivial knob in the GUI to switch to "I don't care. My broken game is
more important!" mode, while still maintaining the only sensible default
of preventing damage for the general use case of the generic distro
kernel.

Thanks,

        tglx

  reply	other threads:[~2022-10-06 20:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-28 14:21 [PATCH] x86/split_lock: Restore warn mode (and add a new one) to avoid userspace regression Guilherme G. Piccoli
2022-09-28 20:24 ` Luck, Tony
2022-09-28 20:50   ` Joshua Ashton
2022-09-28 20:56   ` Guilherme G. Piccoli
2022-10-06 20:15     ` Thomas Gleixner [this message]
2022-10-06 20:58       ` Guilherme G. Piccoli
2022-10-06  9:04   ` Pavel Machek
2022-10-06 15:07     ` Guilherme G. Piccoli
2022-09-28 21:50 ` Dave Hansen
2022-09-29 14:57   ` Guilherme G. Piccoli
2022-09-29 15:17     ` Dave Hansen
2022-09-29 15:30       ` Guilherme G. Piccoli
2022-09-29 16:26         ` Dave Hansen
2022-09-29 17:15           ` Guilherme G. Piccoli
2022-09-29 17:23           ` Paul Gofman
2022-09-29 15:37       ` Luck, Tony
2022-10-30 16:13         ` Lukas Straub
2022-09-29 17:17   ` Zebediah Figura

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pmf4bter.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=gpiccoli@igalia.com \
    --cc=hpa@zytor.com \
    --cc=joshua@froggi.es \
    --cc=kernel-dev@igalia.com \
    --cc=kernel@gpiccoli.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mwen@igalia.com \
    --cc=pavel@denx.de \
    --cc=pgofman@codeweavers.com \
    --cc=pgriffais@valvesoftware.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox