[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] memguard_guard_stack()
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 >>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 04/28/06 6:30 PM >>> On 28 Apr 2006, at 17:03, Jan Beulich wrote: > Is it really intended that the stack size, specifically bumped to 4 > pages in include/asm-x86/config.h for x86-64 when > debugging, gets shrunk to a single page in memguard_guard_stack()? To > me it would seem much more reasonable if indeed > only the first page (or at most, the first two pages) was used as a > guard page here. The only reason that the stack is 4 pages on a 64-bit debug build is because we put syscall-entry trampolines at the start of the per-cpu stack area. Therefore simply allocating 2 pages for a debug stack and then removing the mapping of the first page, as we do on i386, does not work -- that would unmap the trampolines! Instead we allocate 4 pages (next power of two) and zap the middle two page mappings. This has the desirable effect of placing the guard between the trampolines and the actual stack (otherwise the trampolines would get overwritten before the guard page gets trodden on!). It should never be possible for Xen to overflow 4kB of stack. Very little is done in interrupt contexts so we don't have the overflow problems that Linux has suffered. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |