[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1612160937540.3470@nanos>
Date: Fri, 16 Dec 2016 09:47:36 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Andy Lutomirski <luto@...capital.net>
cc: LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Kyle Huey <khuey@...ehuey.com>,
Andy Lutomirski <luto@...nel.org>
Subject: Re: [patch 2/3] x86/process: Optimize TIF_BLOCKSTEP switch
On Thu, 15 Dec 2016, Andy Lutomirski wrote:
> On Thu, Dec 15, 2016 at 8:44 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > +static inline void toggle_debugctlmsr(unsigned long mask)
> > +{
> > + unsigned long msrval;
> > +
> > +#ifndef CONFIG_X86_DEBUGCTLMSR
> > + if (boot_cpu_data.x86 < 6)
> > + return;
> > +#endif
> > + rdmsrl(MSR_IA32_DEBUGCTLMSR, msrval);
> > + wrmsrl(MSR_IA32_DEBUGCTLMSR, msrval ^ mask);
> > +}
> > +
>
> This scares me. If the MSR ever gets out of sync with the TI flag,
> this will malfunction. And IIRC the MSR is highly magical and the CPU
> clears it all by itself under a variety of not-so-well documented
> circumstances.
If that is true, then the code today is broken as well, when the flag has
been cleared and both prev and next have the flag set. Then it won't be
updated for the next task.
The we should not use the TIF flag and store a debugmask in thread info and
do:
if (prev->debugmask || next->debugmask) {
if (static_cpu_has(X86_FEATURE_BLOCKSTEP)) {
rdmsrl(MSR_IA32_DEBUGCTLMSR, msrval);
msrval &= DEBUGCTLMSR_BTF;
msrval |= next->debugmask;
}
}
Thanks,
tglx
Powered by blists - more mailing lists