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.
|