Messages in this thread | | | Date | Fri, 21 Nov 2014 12:01:51 -0500 | From | Steven Rostedt <> | Subject | Re: frequent lockups in 3.18rc4 |
| |
On Fri, Nov 21, 2014 at 11:25:06AM -0500, Tejun Heo wrote: > > * Static percpu areas wouldn't trigger fault lazily. Note that this > is not necessarily because the first percpu chunk which contains the > static area is embedded inside the kernel linear mapping. Depending > on the memory layout and boot param, percpu allocator may choose to > map the first chunk in vmalloc space too; however, this still works > out fine because at that point there are no other page tables and > the PUD entries covering the first chunk is faulted in before other > pages tables are copied from the kernel one.
That sounds correct.
> > * NMI used to be a problem because vmalloc fault handler couldn't > safely nest inside NMI handler but this has been fixed since and it > should work fine from NMI handlers now.
Right. Of course "should work fine" does not excatly mean "will work fine".
> > * Function tracers are problematic because they may end up nesting > inside themselves through triggering a vmalloc fault while accessing > dynamic percpu memory area. This may lead to recursive locking and > other surprises.
The function tracer infrastructure now has a recursive check that happens rather early in the call. Unless the registered OPS specifically states it handles recursions (FTRACE_OPS_FL_RECUSION_SAFE), ftrace will add the necessary recursion checks. If a registered OPS lies about being recusion safe, well we can't stop suicide.
Looking at kernel/trace/trace_functions.c: function_trace_call() which is registered with RECURSION_SAFE, I see that the recursion check is done before the per_cpu_ptr() call to the dynamically allocated per_cpu data.
It looks OK, but...
Oh! but if we trace the page fault handler, and we fault here too we just nuked the cr2 register. Not good.
-- Steve
> > Are there other cases where the lazy vmalloc faults can break things?
| |