Re: What's become with PPC patches?

Hi Sergei,

You are right, I see no other place to put the trap entry/exit elsewhere than in
arch/*/mm/fault.c. I will leave the new "page_fault" event, which is linked to
the handle_mm_fault function : it makes sense to instrument page faults caused
by get_user_pages too.

Mathieu

* Sergei Shtylyov ([email protected]) wrote:
> Hello.
> 
> Mathieu Desnoyers wrote:
> >>>* Mathieu Desnoyers ([email protected]) wrote:
> 
> >>>>Note that there should also be a call to trace_kernel_trap_entry/exit in
> >>>>probe_mm_handle_fault_entry/exit in ltt/probes/ltt-probe-ppc.c (see
> >>>>ltt-probe-i386.c for an example). I will fix in the next releases.
> 
> >>>Fixed in LTTng 0.6.25, please test.
> 
> >>  Given the fact that __handle_mm_fault() is called not only from the 
> >>  arch fault handlers but also from get_user_pages(), this fix doesn't look 
> >>correct to me.
> 
> >I plan to use the following workaround :
> 
> >in
> >void probe_mm_handle_fault_entry(const char *format, ...)
> 
> >        /* Call tracer */
> >        if(in_irq())
> >                trace_kernel_trap_entry(trap_id, (void*)eip);
> 
>    What do traps have in common with irqs?!
>    Answer: not *that* much.
> 
> >        trace_memory_page_fault(address, eip);
> >
> >and
> >void probe_mm_handle_fault_exit(const char *format, ...)
> >
> >
> >        /* Call tracer */
> >        if(in_irq())
> >                trace_kernel_trap_exit();
> 
> >This fix is correct as long as get_user_pages in never called from an
> >interrupt context.
> 
>    Not correct at all, IMO.
> 
> >Mathieu
> 
> WBR, Sergei
> 
OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68