From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH RFC] x86/traps: Improve hypervisor stack
	overflow detection
Date: Fri, 20 Nov 2015 12:52:38 +0000
Message-ID: <564F1796.4070705@citrix.com>
References: <1447954456-17855-1-git-send-email-andrew.cooper3@citrix.com>
	<564F09EE02000078000B7118@prv-mh.provo.novell.com>
	<564EFE1C.4090402@citrix.com>
	<564F1EDF02000078000B71CC@prv-mh.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <564F1EDF02000078000B71CC@prv-mh.provo.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Atom2 <ariel.atom2@web2web.at>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 20/11/15 12:23, Jan Beulich wrote:
>>>> On 20.11.15 at 12:03, <andrew.cooper3@citrix.com> wrote:
>> On 20/11/15 10:54, Jan Beulich wrote:
>>>>>> On 19.11.15 at 18:34, <andrew.cooper3@citrix.com> 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