Dave Anderson <anderson@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
