Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <0e11f3e5-6a16-4a7a-8e1f-470c45dac64e@codeweavers.com>
Date:   Thu, 29 Sep 2022 12:17:06 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: [PATCH] x86/split_lock: Restore warn mode (and add a new one) to
 avoid userspace regression
Content-Language: en-US
To:     Dave Hansen <dave.hansen@intel.com>,
        "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>
References: <20220928142109.150263-1-gpiccoli@igalia.com>
 <24f31510-5b33-ada5-9f0e-117420403e8c@intel.com>
From:   Zebediah Figura <zfigura@codeweavers.com>
In-Reply-To: <24f31510-5b33-ada5-9f0e-117420403e8c@intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 9/28/22 16:50, Dave Hansen wrote:
> 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.

This seems like a reasonable position, but on the other hand...

> The other option is to wait and see if there's any kind of pattern with
> these reports.

...if the pattern ends up being "closed-source Windows software", as is 
not unlikely, then maybe this is something that could be made into a 
personality, that emulators like Wine could enable? I don't know how 
distasteful such optional workarounds are in general, but this would at 
least allow the original warning to continue working as intended for 
software that can be fixed.

ἔρρωσθε,
Zeb