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

[HATAYAMA Daisuke]

From: Dave Anderson <anderson at redhat.com>
Subject: Re: [Crash-utility] [PATCH] do not check sp if ip points to user space
Date: Tue, 27 Sep 2011 08:46:27 -0400 (EDT)

> 
> 
> ----- 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.

I had been concerned about the fact that, if such situation was true,
users could lose backtrace in kernel side until the firmware path.
According to your answer, it seems to me that interrupts mechanism
properly resumes its context when returning from firmware.

Of couse I'll follow up this locally further because I had not
confirmed this in specification level. But it's very helpful for
understanding. Thanks for answering to the question.

Thanks.
HATAYAMA, Daisuke