WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] memguard_guard_stack()

>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 01.05.06 16:09 >>>
>
>On 1 May 2006, at 12:36, Jan Beulich wrote:
>
>> Hmm, but I found this precisely because we saw a double fault due to a 
>> stack overflow. Admittedly this was in the
>> context of one of these IPI storms during shotdown that were fixed 
>> previously, but even that shouldn't result in a stack
>> overflow, should it ? Jan
>
>How many CPUs were in the system? That code path was rather dodgy: the 
>function forcibly enabled interrupts and so a single CPU could nest in 
>that function up to (NR_CPUS-1) times which, if you had say 32 CPUs in 
>the system could certainly cause problems. I don't think it's 
>indicative of a wider problem in Xen -- for most interrupts (ones bound 
>to a guest) we don't even reenable interrupt delivery while handling 
>them, so nested ISRs in Xen are impossible.

At least 16 (both stack traces we got were on CPU 15.

>I would like to understand exactly what happened in the context of your 
>IPI storm (it *is* the machine restart bug we're talking about, right?) 

Yes.

>-- if you had much fewer than 32 CPUs then I need to check exactly how 
>much stack an invocation of machine_restart() uses.

A single nesting level consumed, according to the stack dump, up to 352 bytes.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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