Messages in this thread | | | Subject | Re: [tip: x86/splitlock] Documentation/x86: Add buslock.rst | From | Xiaoyao Li <> | Date | Wed, 18 Aug 2021 09:59:49 +0800 |
| |
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.
| |