Re: [Crash-utility] [PATCH] Fix x86 initialization for {hard, soft}irq_ctx
Dave Anderson <anderson(a)redhat.com> writes:
> > Please review the attached update to your patch, which adds
support for
> > the irq_ctx-to-irq_stack transition.
> > - if ((hard_sp = per_cpu_symbol_search("per_cpu__hardirq_ctx"))) {
> > + if ((hard_sp = per_cpu_symbol_search("per_cpu__hardirq_ctx")) ||
> > + (hard_sp = per_cpu_symbol_search("per_cpu__hardirq_stack"))) {
> > if ((kt->flags & SMP) && (kt->flags & PER_CPU_OFF)) {
> > for (i = 0; i < NR_CPUS; i++) {
> > + ulong ptr;
> > +
>
> [...]
>
> Right, this will work, maybe, several stuffs. However hardirq_tasks[] is
> missing, so this will not be fully. For now, I don't have dump of other
> than v4.9 (stack format was changed), so I'm not sure which commands are
> not working (user of hardirq_tasks[]).
I haven't looked at the recent kernel to check out how the linkage is done
without the temporary thread_info at the bottom of the hard/soft irq stacks,
but looking at a live 4.9 system, it looks like the first word at the base of
the hard and soft irq stack now contains a pointer into the stack of the
last caller? If that's true, then stkptr_to_task() could be used to
populate the hardirq_tasks[] and softirq_tasks[] -- but the initialization
would have to be delayed until near the end of task_init().
Right. At least on v4.9, with quick check, looks like the x86 and x86_64
has different (x86 is for hardirq/softirq, x86_64 is for
hardirq/exception).
linux/arch/x86/kernel/dumpstack_{32,64}.c is how get previous stack from
sp.
x86:
in_hardirq_stack(stack, info)
info->next_sp = (unsigned long *)*begin;
in_softirq_stack(stack, info)
info->next_sp = (unsigned long *)*begin;
both is same as you said (at start of stack pages).
x86_64
in_exception_stack(stack, info)
info->next_sp = (unsigned long *)regs->sp;
in_irq_stack(stack, info)
info->next_sp = (unsigned long *)*(end - 1);
exception has pt_regs at top of stack (at end of stack pages)
irq has previous sp at top of stack (at end of stack pages)
But I'm still not checking when switched to this format, and how
consolidate/coding those in crash.
--
OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp>