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