[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <24f31510-5b33-ada5-9f0e-117420403e8c@intel.com>
Date: Wed, 28 Sep 2022 14:50:00 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Guilherme G. Piccoli" <gpiccoli@...lia.com>, tony.luck@...el.com,
tglx@...utronix.de, linux-kernel@...r.kernel.org, x86@...nel.org
Cc: mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
hpa@...or.com, luto@...nel.org, kernel-dev@...lia.com,
kernel@...ccoli.net, Fenghua Yu <fenghua.yu@...el.com>,
Joshua Ashton <joshua@...ggi.es>,
Paul Gofman <pgofman@...eweavers.com>,
Pavel Machek <pavel@...x.de>,
Pierre-Loup Griffais <pgriffais@...vesoftware.com>,
Melissa Wen <mwen@...lia.com>
Subject: Re: [PATCH] x86/split_lock: Restore warn mode (and add a new one) to
avoid userspace regression
I really don't like the idea of *both* a new boot parameter and a new
Kconfig option.
The warning mode worked as intended in this case because it got a user
to file a bug and that bug report made it back to us. It's kinda funny
to respond to that report by reducing the misery.
On the other hand, all the report resulted in was finger-pointing at a
binary Windows applications that neither we nor probably anybody else
can do anything about.
It boils down to either:
* The misery is good and we keep it as-is, or
* The misery is bad and we kill it
My gut says we should keep the warnings and kill the misery. The folks
who are going to be able to fix the issues are probably also the ones
looking at dmesg and don't need the extra hint from the misery. The
folks running Windows games don't look at dmesg and just want to play
their game without misery.
The other option is to wait and see if there's any kind of pattern with
these reports.
Powered by blists - more mailing lists