Re: [PATCH v10 5/6] x86/split_lock: Handle #AC exception for split lock

[Andy Lutomirski]

> On Nov 21, 2019, at 3:02 PM, Fenghua Yu <fenghua.yu@xxxxxxxxx> wrote:
> 
> ïOn Thu, Nov 21, 2019 at 02:10:38PM -0800, Andy Lutomirski wrote:
>> 
>> 
>>>> On Nov 20, 2019, at 5:45 PM, Fenghua Yu <fenghua.yu@xxxxxxxxx> wrote:
>>> 
>>> +    if (!user_mode(regs) && split_lock_detect_enabled)
>>> +        panic("Split lock detected\n");
>> 
>> NAK.
>> 
>> 1. Donât say âsplit lock detectedâ if you donât know that you detected a split lock.  Or is this genuinely the only way to get #AC from kernel mode?
> 
> Intel hardware design team confirmed that the only reason for #AC in ring 0 is
> split lock.

Okay.

This should eventually get integrated with Jannâs decoder work to print the lock address and size.

> 
>> 
>> 2. Donât panic. Use die() just like every other error where nothing is corrupted.
> 
> Ok. Will change to die() which provides all the trace information and
> allow multiple split lock in one boot.
> 
>> 
>> And maybe instead turn off split lock detection and print a stack trace instead.  Then the kernel is even more likely to survive to log something useful.
> 
> How about we just use simple policy die() in this patch set to allow
> detect and debug split lock issues and extend the code base to handle
> split lock with different policies (panic, disable split lock, maybe other
> options) in the future?
> 
> 

Iâm okay with this.  Peter?

>