On Tue, Sep 13, 2016 at 08:29:57PM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf <jpoim...@redhat.com> wrote: > > > show_stack_log_lvl() and dump_trace() are already preemption safe: > > > > - If they're running in irq or exception context, preemption is already > > disabled and the percpu stack pointers can be trusted. > > > > - If they're running with preemption enabled, they must be running on > > the task stack anyway, so it doesn't matter if they're comparing the > > stack pointer against a percpu stack pointer from this CPU or another > > one: either way it won't match. > > Yeah, so I'm having second thoughts about this patch. My worry here is: what > if we > get preempted in this sequence? > > If the kernel is borked real bad then we could get technically correct but > really, > really weird looking stack traces if for example the task stack is getting > corrupted or something like that.
If it's in the oops or BUG path, there can't be preemption anyway because oops_begin() disables interrupts. It does look like the WARN path could get preempted. Not to mention all the other callers of show_regs(), dump_stack(), show_stack_log_lvl(), etc. In those cases, if the stack dump got preempted in the middle, and then another task dumped its stack, the two dumps could be interspersed a bit which would indeed be a little confusing. But that would be quite rare. And anyway, we already have the same issue today when two CPUs are dumping the stack at the same time. So I don't think it's much of an issue. > Dunno. How long does the worst-case processing here take on a typical x86 > system, > does it really matter to scheduling latency? I haven't heard any complaints about latency. The goal was just to try to simplify the code a bit. -- Josh
