This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] stack overflow during pv-guest restore

To: Jan Beulich <jbeulich@xxxxxxxxxx>, <ddutile@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] stack overflow during pv-guest restore
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 01 Feb 2008 10:34:42 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 01 Feb 2008 02:36:05 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47A2F567.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Achkvg3pTEg1k9CxEdymRgAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH] stack overflow during pv-guest restore
User-agent: Microsoft-Entourage/
Good point, I'll confirm that and take that approach instead, protected with
some kind of BUG_ON(!spin_trylock) on a private lock for sanity's sake.

 -- Keir

On 1/2/08 09:33, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> I think this can be fixed with a much smaller change: Since the only caller
> of cpu_initialize_context() is __cpu_up(), and since __cpu_up() invocation
> is serialized, the variable in question could simply be static.
> Jan
>>>> Don Dutile <ddutile@xxxxxxxxxx> 31.01.08 21:05 >>>
> When secondary cpus are initialized during an i386 pv-guest restore
> (due to save/restore or live migration), and the guest has
> a load that generates a fair number of interrupts (e.g., parallel kernel
> make),
> a stack overflow can occur because cpu_initialize_context() has
> a 2800 byte structure it declares on its stack.  linux-i386 has 4K stacks, by
> default.
> Using 2800 bytes out of 4K by a single function in a call list isn't nice;
> add the beginning of interrupt handling at just the right point, before the
> switch to the interrupt stack is made... and... the scale tips...
> Simple fix: malloc & free structure as needed.
> Would fail save/restore testing of an i386-guest running a parallel, kernel
> make after
> 50->100 save/restores;  with the fix, haven't seen it fail after 650
> save/restores.
> Note: this is a basic port of this function in Jeremy Fitzharinge's Xen
> implementation of pv-ops
>        in upstream Linux, part of 15/32 patch, Xen SMP guest support.
> Original patch done on rhel5; did a simple diff & merge to xen-unstable's
> version
> of smpboot.c to generate the attached patch, so it cleanly applies; but
> haven't built/run/tested the xen-unstable version.
> Signed-off-by: Donald Dutile <ddutile@xxxxxxxxxx>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>