Re: [Xen-devel] [PATCH RFC] x86/traps: Improve hypervisor stack overflow detection

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 20/11/15 12:23, Jan Beulich wrote:
>>>> On 20.11.15 at 12:03, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 20/11/15 10:54, Jan Beulich wrote:
>>>>>> On 19.11.15 at 18:34, <andrew.cooper3@xxxxxxxxxx> wrote:
>>>> @@ -394,9 +401,8 @@ void show_stack_overflow(unsigned int cpu, const 
>>>> struct 
>> cpu_user_regs *regs)
>>>>             (void *)esp_top, (void *)esp_bottom, (void *)esp,
>>>>             (void *)per_cpu(init_tss, cpu).esp0);
>>>>  
>>>> -    /* Trigger overflow trace if %esp is within 512 bytes of the guard 
>>>> page. 
>> */
>>>> -    if ( ((unsigned long)(esp - esp_top) > 512) &&
>>>> -         ((unsigned long)(esp_top - esp) > 512) )
>>>> +    /* Trigger overflow trace if %esp is anywhere within the guard page. 
>>>> */
>>>> +    if ( (esp & PAGE_MASK) != (esp_top - PAGE_SIZE) )
>>> Is this correct? I'd suspect this to be wrong when esp is in the
>>> lower of the two primary stack pages.
>> If we have hit a double fault from the stack guard pages, one way or
>> another %esp is somewhere in the guard page.
> But the #DF may be for a reason other than having run into a
> stack guard page.

Indeed, but under such circumstances, we don't want to continue with the
stack overflow analysis.

I had some other ideas about dumping some other state in the #DF
handler, but that is an independent change.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel