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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 20.11.15 at 13:52, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

Oh, right, the right side is the guard page (the "top" vs "bottom"
use is somewhat confusing when you consider memory addresses
instead of the direction the stack grows).

Jan


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