Re: [PATCH 0/2] [GIT PULL] tracing: various bug fixes

[Ingo Molnar <mingo@elte.hu>]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Thu, 23 Apr 2009, Steven Rostedt wrote:
> > 
> > static inline void __native_flush_tlb_global(void)
> > {
> >         unsigned long flags;
> >         unsigned long cr4;
> > 
> >         /*
> >          * Read-modify-write to CR4 - protect it from preemption and
> >          * from interrupts. (Use the raw variant because this code can
> >          * be called from deep inside debugging code.)
> >          */
> >         raw_local_irq_save(flags);
> > 
> >         cr4 = read_cr4();
> >         /* clear PGE */
> >         write_cr4(cr4 & ~X86_CR4_PGE);
> >         /* write old PGE again and flush TLBs */
> >         write_cr4(cr4);
> > 
> >         raw_local_irq_restore(flags);
> > }
> > 
> > 
> > Each of those read_cr4 and write_cr4 can be traced. But I still do not see 
> > how this can cause corruption in the current task struct.
> > 
> > The TLB just caches the pages we are using, not the contents 
> > inside. I still do not see how this can corrupt a bit. Unless a 
> > register leaked :-/
> 
> Ah, this is a lockdep thing.
> 
> The raw_local_irq_save/restore in __native_flush_tlb_global does 
> not update hardirqs_enabled.
> 
> When we call into ftrace, when we cross page bounderies, we 
> disable interrupts using the normal local_irq_save/restore calls.
> 
> But when we restore, it detects that interrupts are not going to 
> be enabled, and keeps hardirqs_enabled off.

ah, so the problem is ftrace doing a function trace entry _in the 
middle_ of the raw-irqs section in __native_flush_tlb_global()? (due 
to the cr4 getting virtualized too)

Nasty, really nasty.

	Ingo