All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Benjamin Lamowski <benjamin.lamowski@kernkonzept.com>
Cc: xiaoyao.li@intel.com, philipp.eppelt@kernkonzept.com,
	bp@alien8.de, fenghua.yu@intel.com, hpa@zytor.com,
	linux-kernel@vger.kernel.org, luto@kernel.org, mingo@redhat.com,
	nivedita@alum.mit.edu, pbonzini@redhat.com, peterz@infradead.org,
	tglx@linutronix.de, tony.luck@intel.com, x86@kernel.org
Subject: Re: [PATCH 1/1] x86/split_lock: check split lock feature on initialization
Date: Fri, 3 Apr 2020 11:01:49 -0700	[thread overview]
Message-ID: <20200403180149.GH2701@linux.intel.com> (raw)
In-Reply-To: <20200403174403.306363-2-benjamin.lamowski@kernkonzept.com>

On Fri, Apr 03, 2020 at 07:44:03PM +0200, Benjamin Lamowski wrote:
> While the setup code probes for the availability of the TEST_CTRL MSR,
> the current initialization code unconditionally probes it even on
> systems where this architectural MSR is not available.
> 
> This commit changes the code to check for the availability of the split
> lock detect feature before initializing it.
> 
> Fixes: dbaba47085b0c ("x86/split_lock: Rework the initialization flow of split lock detection")
> Signed-off-by: Benjamin Lamowski <benjamin.lamowski@kernkonzept.com>
> ---
>  arch/x86/kernel/cpu/intel.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
> index 9a26e972cdea..70d338ff4807 100644
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -586,7 +586,7 @@ static void init_intel_misc_features(struct cpuinfo_x86 *c)
>  	wrmsrl(MSR_MISC_FEATURES_ENABLES, msr);
>  }
>  
> -static void split_lock_init(void);
> +static void split_lock_init(struct cpuinfo_x86 *c);
>  
>  static void init_intel(struct cpuinfo_x86 *c)
>  {
> @@ -703,7 +703,7 @@ static void init_intel(struct cpuinfo_x86 *c)
>  	if (tsx_ctrl_state == TSX_CTRL_DISABLE)
>  		tsx_disable();
>  
> -	split_lock_init();
> +	split_lock_init(c);
>  }
>  
>  #ifdef CONFIG_X86_32
> @@ -1061,9 +1061,10 @@ static void sld_update_msr(bool on)
>  	wrmsrl(MSR_TEST_CTRL, test_ctrl_val);
>  }
>  
> -static void split_lock_init(void)
> +static void split_lock_init(struct cpuinfo_x86 *c)
>  {
> -	split_lock_verify_msr(sld_state != sld_off);
> +	if (cpu_has(c, X86_FEATURE_SPLIT_LOCK_DETECT))
> +		split_lock_verify_msr(sld_state != sld_off);

Calling split_lock_verify_msr() with X86_FEATURE_SPLIT_LOCK_DETECT=0 is
intentional, the idea is to ensure SLD is disabled on all CPUs, e.g. in the
unlikely scenario that BIOS enabled SLD.

The first rdmsrl_safe() should short circuit split_lock_verify_msr() if
the RDMSR faults, i.e. it might fault, but it shouldn't WARN.  Are you
seeing issues or was this found via code inspection?

>  }
>  
>  bool handle_user_split_lock(struct pt_regs *regs, long error_code)
> -- 
> 2.25.1
> 

  reply	other threads:[~2020-04-03 18:01 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
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 [this message]
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=20200403180149.GH2701@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=benjamin.lamowski@kernkonzept.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=philipp.eppelt@kernkonzept.com \
    --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.