[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180623042033.GF18979@romley-ivt3.sc.intel.com>
Date: Fri, 22 Jun 2018 21:20:33 -0700
From: Fenghua Yu <fenghua.yu@...el.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Fenghua Yu <fenghua.yu@...el.com>, Ingo Molnar <mingo@...e.hu>,
"H. Peter Anvin" <hpa@...ux.intel.com>,
Ashok Raj <ashok.raj@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
Rafael Wysocki <rafael.j.wysocki@...el.com>,
Tony Luck <tony.luck@...el.com>,
Alan Cox <alan@...ux.intel.com>,
Ravi V Shankar <ravi.v.shankar@...el.com>,
Arjan van de Ven <arjan@...radead.org>,
linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>
Subject: Re: [RFC PATCH 02/16] x86/split_lock: Handle #AC exception for split
lock in kernel mode
On Fri, Jun 22, 2018 at 12:49:00PM +0200, Thomas Gleixner wrote:
> On Sun, 27 May 2018, Fenghua Yu wrote:
> > +static void wait_for_reexecution(void)
> > +{
> > + while (time_before(jiffies, disable_split_lock_jiffies +
> > + reenable_split_lock_delay))
> > + cpu_relax();
> > +}
> > +
> > +/*
> > + * TEST_CTL MSR is shared among threads on the same core. To simplify
> > + * situation, disable_split_lock_jiffies is global instead of per core.
>
> This patch surely earns extra points in the trainwreck engineering contest,
> but that's not taking place on LKML.
>
> The whole thing is simply:
>
> handle_ac()
> {
> if (user_mode(regs)) {
> do_trap(AC, SIGBUS, ...);
> } else {
> disable_ac_on_local_cpu();
> WARN_ONCE(1);
> }
> }
Should I add kernel parameter or control knob to opt-out the feature?
I'm afraid firmware may hang system after handling split lock if the
feature is enabled by kernel, e.g. "reboot" hits split lock in firmware
and firmware hangs the system after handling #AC.
Thanks.
-Fenghua
Powered by blists - more mailing lists