Re: [PATCH v2] [LBR] Dump LBRs on Exception

[Andy Lutomirski]

On Tue, Dec 2, 2014 at 11:56 AM, Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Tue, 2 Dec 2014, Andy Lutomirski wrote:
>> TBH, I'm wondering whether this is actually a good idea.  It might be
>> more valuable and less scary to try to make this work for BUG instead.
>> To get the most impact, it might be worth allocating a new exception
>> vector for BUG and using 'int 0xwhatever', and the prologue to that
>> could read out all the MSRs without any branches.
>
> BUG is pretty uninteresting. We usually know how we got there. Now
> where LBR might be useful is if you have stack corruption and branch
> into nirvana or access random crap via a few hoops. There the LBR data
> might help, because the corrupted stack does not tell anything.
>
> So yes, this is a corner case debugging scenario, but given the
> complexity of coordination with perf and the possible intrusiveness in
> the low level entry path, we really need to see a few real world
> examples where this helps, aside of the constructed case.
>

One option would be to treat this as the debugging feature that it is.

Don't change the exception entry code at all.  Instead add a run-time
switch that will ask perf to set up the LBR stuff appropriately and
will change the IDT entries to stubs that first use rdmsr to copy all
the LBRs to some per-cpu, per-vector area and then jump to the real
entry point.

Yes, performance will suck, and there will be some artifacts if the
exception nests inside itself before reporting the error (which can
happen for page faults, I think), but this isn't the end of the world
if it's an opt-in feature.

And the whole pile of rdmsrs can be generated at run-time to match the
running CPU.

--Andy

> Thanks,
>
>         tglx



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/