From: Xiaoyao Li <xiaoyao.li@intel.com>
To: linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org
Cc: Fenghua Yu <fenghua.yu@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Tony Luck <tony.luck@intel.com>,
x86@kernel.org
Subject: Re: [tip: x86/splitlock] Documentation/x86: Add buslock.rst
Date: Wed, 18 Aug 2021 09:59:49 +0800 [thread overview]
Message-ID: <f1a30c67-2c05-5c8f-df8f-ca82f9bf89af@intel.com> (raw)
In-Reply-To: <162134906278.29796.13820849234959966822.tip-bot2@tip-bot2>
On 5/18/2021 10:44 PM, tip-bot2 for Fenghua Yu wrote:
...
> +
> +Software handling
> +=================
> +
> +The kernel #AC and #DB handlers handle bus lock based on the kernel
> +parameter "split_lock_detect". Here is a summary of different options:
> +
> ++------------------+----------------------------+-----------------------+
> +|split_lock_detect=|#AC for split lock |#DB for bus lock |
> ++------------------+----------------------------+-----------------------+
> +|off |Do nothing |Do nothing |
> ++------------------+----------------------------+-----------------------+
> +|warn |Kernel OOPs |Warn once per task and |
> +|(default) |Warn once per task and |and continues to run. |
> +| |disable future checking | |
> +| |When both features are | |
> +| |supported, warn in #AC | |
> ++------------------+----------------------------+-----------------------+
> +|fatal |Kernel OOPs |Send SIGBUS to user. |
> +| |Send SIGBUS to user | |
> +| |When both features are | |
> +| |supported, fatal in #AC | |
> ++------------------+----------------------------+-----------------------+
> +
Hi all,
I'm wonder if using only one "split_lock_detect" parameter for those two
features is good/correct.
In fact, split lock is just one type of bus lock. There are two types
bus lock:
1) split lock, lock on WB memory across multiple cache lines;
2) lock on non-WB memory;
As current design, if both features are available, it only enables #AC
for split lock either for "warn" or "fatal". Thus we cannot capture any
bus lock due to 2) lock on non-WB memory.
Why not provide separate parameter for them? e.g., split_lock_detect and
bus_lock_detect. Then they can be configured and enabled independently.
next prev parent reply other threads:[~2021-08-18 1:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-19 21:49 [PATCH 0/4] x86/bus_lock: Set rate limit for bus lock Fenghua Yu
2021-04-19 21:49 ` [PATCH 1/4] Documentation/x86: Add buslock.rst Fenghua Yu
2021-05-18 14:39 ` Thomas Gleixner
2021-05-18 14:44 ` [tip: x86/splitlock] " tip-bot2 for Fenghua Yu
2021-08-18 1:59 ` Xiaoyao Li [this message]
2021-08-18 15:36 ` Fenghua Yu
2021-08-19 3:36 ` Xiaoyao Li
2021-04-19 21:49 ` [PATCH 2/4] x86/bus_lock: Set rate limit for bus lock Fenghua Yu
2021-05-18 14:44 ` [tip: x86/splitlock] " tip-bot2 for Fenghua Yu
2021-04-19 21:49 ` [PATCH 3/4] Documentation/admin-guide: Change doc for bus lock ratelimit Fenghua Yu
2021-05-18 14:44 ` [tip: x86/splitlock] Documentation/admin-guide: Add " tip-bot2 for Fenghua Yu
2021-04-19 21:49 ` [PATCH 4/4] Documentation/x86: Add ratelimit in buslock.rst Fenghua Yu
2021-05-18 14:44 ` [tip: x86/splitlock] " tip-bot2 for Fenghua Yu
2021-05-17 18:46 ` [PATCH 0/4] x86/bus_lock: Set rate limit for bus lock Fenghua Yu
2021-05-17 19:01 ` Thomas Gleixner
2021-05-17 19:05 ` 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=f1a30c67-2c05-5c8f-df8f-ca82f9bf89af@intel.com \
--to=xiaoyao.li@intel.com \
--cc=fenghua.yu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--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 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.