[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH RFC] x86/traps: Improve hypervisor stack overflow detection
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |