RE: [RFD] x86/split_lock: Request to Intel

2019-10-18 Thread hpa
On October 18, 2019 3:45:14 AM PDT, David Laight wrote: >From: Luck, Tony >> Sent: 18 October 2019 00:28 >... >> 2) Fix set_bit() et. al. to not issue atomic operations that cross >boundaries. >> >> Fenghua had been pursuing option #1 in previous iterations. He found >a few >> more places with

RE: [RFD] x86/split_lock: Request to Intel

2019-10-18 Thread David Laight
From: Luck, Tony > Sent: 18 October 2019 00:28 ... > 2) Fix set_bit() et. al. to not issue atomic operations that cross boundaries. > > Fenghua had been pursuing option #1 in previous iterations. He found a few > more places with the help of the "grep" patterns suggested by David Laight. > So

Re: [RFD] x86/split_lock: Request to Intel

2019-10-18 Thread Peter Zijlstra
On Fri, Oct 18, 2019 at 06:20:44PM +0800, Xiaoyao Li wrote: > We enable #AC on all cores/threads to detect split lock. > -If user space causes #AC, sending SIGBUS to it. > -If kernel causes #AC, we globally disable #AC on all cores/threads, > letting kernel go on working and WARN. (only

Re: [RFD] x86/split_lock: Request to Intel

2019-10-18 Thread Xiaoyao Li
On 10/18/2019 5:02 PM, Thomas Gleixner wrote: On Fri, 18 Oct 2019, Xiaoyao Li wrote: On 10/17/2019 8:29 PM, Thomas Gleixner wrote: The more I look at this trainwreck, the less interested I am in merging any of this at all. The fact that it took Intel more than a year to figure out that the

Re: [RFD] x86/split_lock: Request to Intel

2019-10-18 Thread Thomas Gleixner
On Fri, 18 Oct 2019, Xiaoyao Li wrote: > On 10/17/2019 8:29 PM, Thomas Gleixner wrote: > > The more I look at this trainwreck, the less interested I am in merging any > > of this at all. > > > > The fact that it took Intel more than a year to figure out that the MSR is > > per core and not per

Re: [RFD] x86/split_lock: Request to Intel

2019-10-17 Thread Xiaoyao Li
On 10/17/2019 8:29 PM, Thomas Gleixner wrote: The more I look at this trainwreck, the less interested I am in merging any of this at all. The fact that it took Intel more than a year to figure out that the MSR is per core and not per thread is yet another proof that this industry just works by

Re: [RFD] x86/split_lock: Request to Intel

2019-10-17 Thread Sean Christopherson
On Thu, Oct 17, 2019 at 11:31:15PM +0200, Thomas Gleixner wrote: > On Thu, 17 Oct 2019, Sean Christopherson wrote: > > On Thu, Oct 17, 2019 at 02:29:45PM +0200, Thomas Gleixner wrote: > > > The more I look at this trainwreck, the less interested I am in merging > > > any > > > of this at all. > >

RE: [RFD] x86/split_lock: Request to Intel

2019-10-17 Thread Luck, Tony
> If that's not going to happen, then we just bury the whole thing and put it > on hold until a sane implementation of that functionality surfaces in > silicon some day in the not so foreseeable future. We will drop the patches to flip the MSR bits to enable checking. But we can fix the split

Re: [RFD] x86/split_lock: Request to Intel

2019-10-17 Thread Thomas Gleixner
On Thu, 17 Oct 2019, Sean Christopherson wrote: > On Thu, Oct 17, 2019 at 02:29:45PM +0200, Thomas Gleixner wrote: > > The more I look at this trainwreck, the less interested I am in merging any > > of this at all. > > > > The fact that it took Intel more than a year to figure out that the MSR is

Re: [RFD] x86/split_lock: Request to Intel

2019-10-17 Thread Sean Christopherson
On Thu, Oct 17, 2019 at 02:29:45PM +0200, Thomas Gleixner wrote: > The more I look at this trainwreck, the less interested I am in merging any > of this at all. > > The fact that it took Intel more than a year to figure out that the MSR is > per core and not per thread is yet another proof that