From: Thomas Gleixner <tglx@linutronix.de>
To: Fenghua Yu <fenghua.yu@intel.com>, Borislav Petkov <bp@alien8.de>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Tony Luck <tony.luck@intel.com>,
Randy Dunlap <rdunlap@infradead.org>,
Xiaoyao Li <xiaoyao.li@intel.com>,
Ravi V Shankar <ravi.v.shankar@intel.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>,
Fenghua Yu <fenghua.yu@intel.com>
Subject: Re: [PATCH v4 2/4] x86/bus_lock: Handle warn and fatal in #DB for bus lock
Date: Wed, 27 Jan 2021 22:16:15 +0100 [thread overview]
Message-ID: <87v9bidqsg.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20201124205245.4164633-3-fenghua.yu@intel.com>
On Tue, Nov 24 2020 at 20:52, Fenghua Yu wrote:
> #DB for bus lock is enabled by bus lock detection bit 2 in DEBUGCTL MSR
> while #AC for split lock is enabled by split lock detection bit 29 in
> TEST_CTRL MSR.
>
> Delivery of #DB for bus lock in userspace clears DR6[11]. To avoid
> confusion in identifying #DB, #DB handler sets the bit to 1 before
> returning to the interrupted task.
>
> Use the existing kernel command line option "split_lock_detect=" to handle
> #DB for bus lock:
>
> split_lock_detect=
> #AC for split lock #DB for bus lock
>
> off Do nothing Do nothing
>
> warn Kernel OOPs Warn once per task and
> Warn once per task and and continues to run.
> disable future checking When both features are
> supported, warn in #DB
Which means that we don't catch kernel split locks anymore with 'warn'
if bus lock detection is supported. WHY? There is zero rationale for
this change in the changelog.
> fatal Kernel OOPs Send SIGBUS to user
> Send SIGBUS to user When both features are
> supported, split lock
> triggers #AC and bus lock
> from non-WB triggers #DB.
> /*
> - * Default to sld_off because most systems do not support split lock detection
> - * split_lock_setup() will switch this to sld_warn on systems that support
> - * split lock detect, unless there is a command line override.
> + * Default to sld_off because most systems do not support split lock detection.
> + * sld_state_setup() will switch this to sld_warn on systems that support
> + * split lock/bus lock detect, unless there is a command line override.
> */
> static enum split_lock_detect_state sld_state __ro_after_init = sld_off;
> static u64 msr_test_ctrl_cache __ro_after_init;
> +/* Split lock detection is enabled if it's true. */
> +static bool sld;
Why did you bother with 3 letters? bool s, b; along with comments
explaining what it means would have been sufficient, right?
sld_enable/bld_enable would be too self explaining and this also lacks
__ro_after_init
Aside of that it's beyond silly because bld and sld are just shadowing
the corresponding CPU feature bits. So what are these variables gaining
aside of confusion?
> +/* Bus lock detection is enabled if it's true. */
> +static bool bld;
>
> +static void __init sld_state_setup(void)
This is confusing as hell. sld_state_setup() is used for bus lock as
well and split_lock_detect_state is not less confusing. It took me five
reads to figure out how all of that works.
> +static void __init _split_lock_setup(void)
We generally use two underscores for readability sake.
> +{
> + if (!split_lock_verify_msr(false)) {
> + pr_info("MSR access failed: Disabled\n");
> /*
> @@ -1079,6 +1084,15 @@ static void sld_update_msr(bool on)
>
> static void split_lock_init(void)
> {
> + /*
> + * If supported, #DB for bus lock will handle warn
> + * and #AC for split lock is disabled.
Why does this disable the kernel detection? Just because?
> +void handle_bus_lock(struct pt_regs *regs)
> +{
> + if (!bld)
> + return;
How is #DB ever calling this function when the debug MSR bit is not set?
> -void __init cpu_set_core_cap_bits(struct cpuinfo_x86 *c)
> +static void __init split_lock_setup(struct cpuinfo_x86 *c)
> {
> const struct x86_cpu_id *m;
> u64 ia32_core_caps;
> @@ -1189,5 +1237,43 @@ void __init cpu_set_core_cap_bits(struct cpuinfo_x86 *c)
> }
>
> cpu_model_supports_sld = true;
> - split_lock_setup();
> + _split_lock_setup();
> +}
> +
> +static void sld_state_show(void)
> +{
> + if (!bld && !sld)
> + return;
> +
> + switch (sld_state) {
> + case sld_off:
> + pr_info("disabled\n");
> + break;
> + case sld_warn:
> + if (bld)
> + pr_info("#DB: warning about user-space bus_locks\n");
> + else
> + pr_info("#AC: crashing the kernel about kernel split_locks and warning about user-space split_locks\n");
crashing about?
> + break;
> + case sld_fatal:
> + if (sld)
> + pr_info("#AC: crashing the kernel on kernel split_locks and sending SIGBUS on user-space split_locks\n");
> + if (bld)
> + pr_info("#DB: sending SIGBUS on user-space bus_locks%s\n", sld ? " from non-WB" : "");
> + break;
> + }
Thanks,
tglx
next prev parent reply other threads:[~2021-01-27 21:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-24 20:52 [PATCH v4 0/4] x86/bus_lock: Enable bus lock detection Fenghua Yu
2020-11-24 20:52 ` [PATCH v4 1/4] x86/cpufeatures: Enumerate #DB for " Fenghua Yu
2021-01-27 21:13 ` Thomas Gleixner
2021-01-27 22:39 ` Yu, Fenghua
2021-01-27 23:23 ` Thomas Gleixner
2020-11-24 20:52 ` [PATCH v4 2/4] x86/bus_lock: Handle warn and fatal in #DB for bus lock Fenghua Yu
2021-01-27 21:16 ` Thomas Gleixner [this message]
2020-11-24 20:52 ` [PATCH v4 3/4] x86/bus_lock: Set rate limit " Fenghua Yu
2021-01-27 21:57 ` Thomas Gleixner
2020-11-24 20:52 ` [PATCH v4 4/4] Documentation/admin-guide: Change doc for split_lock_detect parameter Fenghua Yu
2021-01-27 22:09 ` Thomas Gleixner
2020-12-02 20:36 ` [PATCH v4 0/4] x86/bus_lock: Enable bus lock detection Yu, Fenghua
2021-01-04 19:42 ` Fenghua Yu
2021-01-25 19:27 ` Fenghua Yu
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=87v9bidqsg.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=bp@alien8.de \
--cc=fenghua.yu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=rdunlap@infradead.org \
--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.