Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v10 5/6] x86/split_lock: Handle #AC exception for split lock
Date:   Thu, 21 Nov 2019 15:12:01 -0800
Message-Id: <FB8AAE2A-108E-493A-B5FD-FCBFC1CA1C38@amacapital.net>
References: <20191121231410.GD199273@romley-ivt3.sc.intel.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        H Peter Anvin <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Tony Luck <tony.luck@intel.com>,
        Ashok Raj <ashok.raj@intel.com>,
        Ravi V Shankar <ravi.v.shankar@intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
In-Reply-To: <20191121231410.GD199273@romley-ivt3.sc.intel.com>
To:     Fenghua Yu <fenghua.yu@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Nov 21, 2019, at 3:02 PM, Fenghua Yu <fenghua.yu@intel.com> wrote:
>=20
> =EF=BB=BFOn Thu, Nov 21, 2019 at 02:10:38PM -0800, Andy Lutomirski wrote:
>>=20
>>=20
>>>> On Nov 20, 2019, at 5:45 PM, Fenghua Yu <fenghua.yu@intel.com> wrote:
>>>=20
>>> +    if (!user_mode(regs) && split_lock_detect_enabled)
>>> +        panic("Split lock detected\n");
>>=20
>> NAK.
>>=20
>> 1. Don=E2=80=99t say =E2=80=9Csplit lock detected=E2=80=9D if you don=E2=80=
=99t know that you detected a split lock.  Or is this genuinely the only way=
 to get #AC from kernel mode?
>=20
> 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=E2=80=99s decoder work to pr=
int the lock address and size.

>=20
>>=20
>> 2. Don=E2=80=99t panic. Use die() just like every other error where nothi=
ng is corrupted.
>=20
> Ok. Will change to die() which provides all the trace information and
> allow multiple split lock in one boot.
>=20
>>=20
>> And maybe instead turn off split lock detection and print a stack trace i=
nstead.  Then the kernel is even more likely to survive to log something use=
ful.
>=20
> 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?
>=20
>=20

I=E2=80=99m okay with this.  Peter?

>=20