[Crash-utility] [PATCH] do not check sp if ip points to user space

[Dave Anderson]

----- Original Message -----
>
> > Right, but the fact of the matter is that a backtrace cannot be
> > performed for a task with a nonsensical SP value, so it doesn't
> > make a difference whether it was in user-space or kernel-space.
> > So the "cannot determine starting stack pointer" error message
> > should still be displayed as it currently does -- and with my patch
> > suggestion, the registers can be dumped (if available) before
> > returning.
> > 
> 
> I understand. The condition to be used here is whether the backtrace
> can be performed or not, implied by SP values pointing at outside a
> variety of kernel stacks; I guess this is the definition of
> nonsensical SP you've mean. I think the new behaviour reasonable.
> 
> By the way, I have a question that what intension do you have behind
> !is_kernel_text(ip)? Just to exclude the case of user text? I guess
> you're intending here also to exclude other possibilities.

Right, just to prevent the inadvertent setting of BT_USER_SPACE.
 
> Because sadump runs beyond the logic of kernel, register values
> contained in vmcore sometimes the ones in real-address mode, appearing
> having run in some firmware, which often happens at crash during boot
> time.

That's news to me.  I don't know how you would want the backtrace 
mechanism to perform in that case, but I'm presuming that you would
*not* want BT_USER_SPACE set.

> I'm also wondering if there's other dump mechanism that can lead to
> this kind of situation. For example, although I don't understand
> detailed behaviour of NMI, if assuming NMI immediately triggered even
> when running in firmware without rolling back register values saved
> when entering the firmware context from kernel, register values in NMI
> frames would be the ones in firmware and it would be concluded that
> the situation can happen on kdump (and others that uses NMI); but I
> have never seen such register values on kdump...

I've never seen, or heard of, such a situation.  I would guess that
the design of SMI interrupts would prevent that from happening.

Dave