Re: [PATCH 1/1] Fix int1 recursion when no perf_bp_event is registeredy

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 10 Dec 2015, Andy Lutomirski wrote:
> On Thu, Dec 10, 2015 at 12:49 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Thu, 10 Dec 2015, Andy Lutomirski wrote:
> >> On brief inspection, this smells like a microcode bug.  Can you send
> >> /proc/cpuinfo output?
> >>
> >> If this is the issue, I'm not sure we want to be in the business of
> >> working around localized microcode bugs and, if we do, then I think we
> >> should explicitly detect the bug and log about it.
> >
> > I think we should handle such stuff gracefully. Yes, we should log it
> > and we also should check what the contents of the debug registers are.
> >
> > If dr7 has a break point enabled w/o perf having one installed then we
> > know that someone did a horrible hackery ....
> 
> I mis-read this.  I don't think this is the microcode bug.
> 
> Do we know what the actual problem is? Jeff, how did you trigger this?
> 
> If it's lazy DR switching (which I haven't looked at the details of),
> then it seems that this could just be triggered by some unfortunate
> combination of perf config and context switching).  But, if so, then I
> think that the proposed fix is wrong -- shouldn't we fix dr7 rather
> than fudging RF to work around this instance of the problem?  After
> all, if we're hitting this condition in a tight userspace loop, we're
> going to destroy performance unless we fix dr7.

Right, if dr7 contains a valid breakpoint and perf does not have one
installed then either that lazy DR stuff is flaky or someone else
fiddled with dr7. In both cases we want to fix dr7 and yell about it.

If we neither have a breakpoint nor dr7 has one enabled then its
something spurious and we certainly want to set RF so the machine can
make progress.

Thanks,

	tglx