[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180622231813.GE18979@romley-ivt3.sc.intel.com>
Date: Fri, 22 Jun 2018 16:18:13 -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 01:59:44PM +0200, Thomas Gleixner wrote:
> On Fri, 22 Jun 2018, Thomas Gleixner wrote:
> > The whole thing is simply:
> >
> > handle_ac()
> > {
> > if (user_mode(regs)) {
> > do_trap(AC, SIGBUS, ...);
> > } else {
> > disable_ac_on_local_cpu();
> > WARN_ONCE(1);
> > }
> > }
> >
> > That wants #AC enabled as early as possible so the kernel gets as much
> > coverage as it can. If it trips in the kernel it's a bug and needs to be
> > fixed and we can them fix ONE by ONE.
>
> That said, #AC is just yet another badly defined and hastily bolted on
> (mis)feature. This should have been:
>
> Bit A: Enable #AC if CPL < 3
> Bit B: Enable #AC if CPL == 3
>
> But that would have been too useful and would allow sensible use of #AC
> without creating software trainwrecks.
>
The two bits would be ideal.
So I will do SIGBUG for user and WARN/disable for kernel in the next version.
Thanks.
-Fenghua
Powered by blists - more mailing lists