From: Dave Hansen <dave.hansen@intel.com>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
tony.luck@intel.com, tglx@linutronix.de,
linux-kernel@vger.kernel.org, x86@kernel.org
Cc: mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, luto@kernel.org, kernel-dev@igalia.com,
kernel@gpiccoli.net, Fenghua Yu <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: Wed, 28 Sep 2022 14:50:00 -0700 [thread overview]
Message-ID: <24f31510-5b33-ada5-9f0e-117420403e8c@intel.com> (raw)
In-Reply-To: <20220928142109.150263-1-gpiccoli@igalia.com>
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.
next prev parent reply other threads:[~2022-09-28 21:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-28 14:21 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
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 [this message]
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=24f31510-5b33-ada5-9f0e-117420403e8c@intel.com \
--to=dave.hansen@intel.com \
--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=tglx@linutronix.de \
--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
all inboxes | Powered by JetHome®