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

[Robert Jarzmik]

Hi Andy,

Andy Lutomirski <luto@xxxxxxxxxxxxxx> writes:
> On Dec 6, 2014 2:31 AM, "Robert Jarzmik" <robert.jarzmik@xxxxxxxxx> wrote:
>> We would have a "LBR resource" variable to track who owns the LBR :
>> - nobody : LBR_UNCLAIMED
>> - the exception handler : LBR_EXCEPTION_DEBUG_USAGE
>
> Which exception handler? There can be several on the stack.
All of them, ie. LBR is used by exception handlers, ie. perf cannot use it, just
as what Emmanuel's patch is doing I think. Or said differently LBR are reserved
for expeption handlers only, whichever have the implementation to use them.

>> - case 3d: kernel exception with a reschedule inside
>> -> exception entry
>> -> test lbr_dump_state == EXCEPTION_OWNED => true => STOP LBR
>> -> exception handling
>> -> context_switch()
>> -> perf cannot touch LBR, nobody can
>> -> test lbr_dump_state == EXCEPTION_OWNED => true => START LBR
>
> Careful. This is still the nested exception, and it just did the wrong thing.
Can you be more explicit about the "wrong" thing ? And would that wrong thing be
solved by a per-cpu reference counter ?

>> I might be very wrong in the description as I'm not that sharp on x86, but is
>> there a flaw in the above cases ?
>>
>> If not, a couple of tests and Thomas's per-cpu variable can solve the issue,
>> while keeping the exception handler code simple as Emmanual has proposed
> (given
>> the additionnal test inclusion - which will be designed to not pollute the
> LBR),
>> and having a small impact on perf to solve the resource acquire issue.
>
> On current kernels, percpu memory is vmalloced, so accessing it can fault, so
> you can't touch percpu memory at all from page_fault until the vmalloc fixup
> runs. Sorry :(
What about INIT_PER_CPU_VAR (as in gdt_page) ? Won't that be mapped all the time
without need for faulting in pages ?

> This is a problem with rdmsr, too.
You mean rdmsr can fault in a non-hypervisor environment ? Because that
definetely opens a new range of corner cases.

> It may be worth fixing that. In fact, it may be worth getting rid of lazy vmap
> entirely.
Your battle ? ;)

Anyway, would a static per-cpu variable (or variables, one about resources
usage, one reference counter) solve our cases (ie. 3d) ?

-- 
Robert
--
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/