lkml.org 
[lkml]   [2019]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v10 5/6] x86/split_lock: Handle #AC exception for split lock
    Date

    > On Nov 21, 2019, at 3:02 PM, Fenghua Yu <fenghua.yu@intel.com> 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@intel.com> 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?

    >

    \
     
     \ /
      Last update: 2019-11-22 00:12    [W:8.540 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site