From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org,
Paolo Bonzini <pbonzini@redhat.com>,
luto@kernel.org, Peter Zijlstra <peterz@infradead.org>,
Arvind Sankar <nivedita@alum.mit.edu>,
Fenghua Yu <fenghua.yu@intel.com>,
Tony Luck <tony.luck@intel.com>
Subject: Re: [PATCH v7 1/2] x86/split_lock: Rework the initialization flow of split lock detection
Date: Sat, 28 Mar 2020 09:32:01 -0700 [thread overview]
Message-ID: <20200328163201.GI8104@linux.intel.com> (raw)
In-Reply-To: <20200325030924.132881-2-xiaoyao.li@intel.com>
On Wed, Mar 25, 2020 at 11:09:23AM +0800, Xiaoyao Li wrote:
> static void __init split_lock_setup(void)
> {
> + enum split_lock_detect_state state = sld_warn;
> char arg[20];
> int i, ret;
>
> - setup_force_cpu_cap(X86_FEATURE_SPLIT_LOCK_DETECT);
> - sld_state = sld_warn;
> + if (!split_lock_verify_msr(false)) {
> + pr_info("MSR access failed: Disabled\n");
A few nits on the error handling.
The error message for this is a bit wonky, lots of colons and it's not
super clear what "Disabled" refers to.
[ 0.000000] x86/split lock detection: MSR access failed: Disabled
Maybe this, so that it reads "split lock detection disabled because the MSR
access failed".
pr_info("Disabled, MSR access failed\n");
And rather than duplicate the error message, maybe use a goto, e.g.
if (!split_lock_verify_msr(false))
goto msr_failed;
...
if (!split_lock_verify_msr(true))
goto msr_failed;
> + return;
> + }
>
> ret = cmdline_find_option(boot_command_line, "split_lock_detect",
> arg, sizeof(arg));
> if (ret >= 0) {
> for (i = 0; i < ARRAY_SIZE(sld_options); i++) {
> if (match_option(arg, ret, sld_options[i].option)) {
> - sld_state = sld_options[i].state;
> + state = sld_options[i].state;
> break;
> }
> }
> }
>
> - switch (sld_state) {
> + switch (state) {
> case sld_off:
> pr_info("disabled\n");
> - break;
> -
> + return;
> case sld_warn:
> pr_info("warning about user-space split_locks\n");
> break;
> -
> case sld_fatal:
> pr_info("sending SIGBUS on user-space split_locks\n");
> break;
> }
> +
> + if (!split_lock_verify_msr(true)) {
> + pr_info("MSR access failed: Disabled\n");
> + return;
> + }
> +
> + sld_state = state;
> + setup_force_cpu_cap(X86_FEATURE_SPLIT_LOCK_DETECT);
> }
>
> /*
> - * Locking is not required at the moment because only bit 29 of this
> - * MSR is implemented and locking would not prevent that the operation
> - * of one thread is immediately undone by the sibling thread.
> - * Use the "safe" versions of rdmsr/wrmsr here because although code
> - * checks CPUID and MSR bits to make sure the TEST_CTRL MSR should
> - * exist, there may be glitches in virtualization that leave a guest
> - * with an incorrect view of real h/w capabilities.
> + * MSR_TEST_CTRL is per core, but we treat it like a per CPU MSR. Locking
> + * is not implemented as one thread could undo the setting of the other
> + * thread immediately after dropping the lock anyway.
> */
> -static bool __sld_msr_set(bool on)
> +static void sld_update_msr(bool on)
> {
> u64 test_ctrl_val;
>
> - if (rdmsrl_safe(MSR_TEST_CTRL, &test_ctrl_val))
> - return false;
> + rdmsrl(MSR_TEST_CTRL, test_ctrl_val);
>
> if (on)
> test_ctrl_val |= MSR_TEST_CTRL_SPLIT_LOCK_DETECT;
> else
> test_ctrl_val &= ~MSR_TEST_CTRL_SPLIT_LOCK_DETECT;
>
> - return !wrmsrl_safe(MSR_TEST_CTRL, test_ctrl_val);
> + wrmsrl(MSR_TEST_CTRL, test_ctrl_val);
> }
>
> static void split_lock_init(void)
> {
> - if (sld_state == sld_off)
> - return;
> -
> - if (__sld_msr_set(true))
> - return;
> -
> - /*
> - * If this is anything other than the boot-cpu, you've done
> - * funny things and you get to keep whatever pieces.
> - */
> - pr_warn("MSR fail -- disabled\n");
> - sld_state = sld_off;
> + split_lock_verify_msr(sld_state != sld_off);
I think it'd be worth a WARN_ON() if this fails with sld_state != off. If
the WRMSR fails, then presumably SLD is off when it's expected to be on.
The implied WARN on the unsafe WRMSR in sld_update_msr() won't fire unless
a task generates an #AC on a non-buggy core and then gets migrated to the
buggy core. Even if the WARNs are redundant, if something is wrong it'd be
a lot easier for a user to triage/debug if there is a WARN in boot as
opposed to a runtime WARN that requires a misbehaving application and
scheduler behavior.
> }
>
> bool handle_user_split_lock(struct pt_regs *regs, long error_code)
> @@ -1071,7 +1083,7 @@ bool handle_user_split_lock(struct pt_regs *regs, long error_code)
> * progress and set TIF_SLD so the detection is re-enabled via
> * switch_to_sld() when the task is scheduled out.
> */
> - __sld_msr_set(false);
> + sld_update_msr(false);
> set_tsk_thread_flag(current, TIF_SLD);
> return true;
> }
> @@ -1085,7 +1097,7 @@ bool handle_user_split_lock(struct pt_regs *regs, long error_code)
> */
> void switch_to_sld(unsigned long tifn)
> {
> - __sld_msr_set(!(tifn & _TIF_SLD));
> + sld_update_msr(!(tifn & _TIF_SLD));
> }
>
> #define SPLIT_LOCK_CPU(model) {X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY}
> --
> 2.20.1
>
next prev parent reply other threads:[~2020-03-28 16:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 3:09 [PATCH v7 0/2] Fix and optimization of split_lock_detection Xiaoyao Li
2020-03-25 3:09 ` [PATCH v7 1/2] x86/split_lock: Rework the initialization flow of split lock detection Xiaoyao Li
2020-03-28 16:32 ` Sean Christopherson [this message]
2020-03-30 13:26 ` Xiaoyao Li
2020-03-30 14:26 ` Sean Christopherson
2020-03-25 3:09 ` [PATCH v7 2/2] x86/split_lock: Avoid runtime reads of the TEST_CTRL MSR Xiaoyao Li
2020-03-28 16:34 ` Sean Christopherson
2020-03-29 9:13 ` Xiaoyao Li
2020-03-30 18:18 ` Sean Christopherson
2020-04-03 17:44 ` [PATCH 0/1] x86/split_lock: check split lock feature on initialization Benjamin Lamowski
2020-04-03 17:44 ` [PATCH 1/1] " Benjamin Lamowski
2020-04-03 18:01 ` Sean Christopherson
2020-04-06 8:23 ` Benjamin Lamowski
2020-04-06 11:48 ` Xiaoyao Li
2020-04-06 15:57 ` [PATCH v2 0/1] x86/split_lock: check split lock support " Benjamin Lamowski
2020-04-06 16:02 ` [PATCH v2 1/1] " Benjamin Lamowski
2020-04-06 16:17 ` [PATCH v3 " Benjamin Lamowski
2020-04-06 21:24 ` Thomas Gleixner
2020-04-07 13:25 ` [PATCH v2 " kbuild test robot
2020-04-06 21:21 ` [PATCH 0/1] x86/split_lock: check split lock feature " Thomas Gleixner
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=20200328163201.GI8104@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=bp@alien8.de \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=nivedita@alum.mit.edu \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.