On 31 July 2012 23:31, Jakub Jermar <[email protected]> wrote: > On 07/30/2012 08:48 PM, Jiří Zárevúcky wrote: >> Jakub has already told me on IRC that current stacks do not grow and >> there is no protection against overflow. > > Yes, for the record, there is an open ticket for this: #382. >
I should start paying attention to those. >> The question is, how difficult would it be to implement growing >> stacks? Is it even possible with the way memory management is >> currently implemented? > > It wouldn't be probably too difficult to allocate stacks so that there > is a guard page at its both ends. One would basically need to tell the > kernel to unmap the guard pages and not allocate their virtual addresses > to someone else. Perhaps a specialized address space area type would do. > > Growing the stacks can be potentially somewhat harder. It would be > necessary to implement a mechanism that would move the as area base to a > lower address, if available. > > The impulse to grow the as area downwards could be inferred by the > kernel from some flag in the address space area or could be a result of > the uspace reacting to some end-of-stack event, as it it implemented > e.g. in Windows. For the latter, the use of kernel notifications comes > to mind. > We could implement some kind of reservation system. That is, application would call something like as_area_reserve() to reserve just a piece of virtual address space, not physical memory. Then there would be another call distinct from as_area_create() that would map pages in a previously reserved region. Is there a way to handle access to unmapped pages from userspace? Speaking of which, Jiri mentioned that most of this virtual address space management should probably be in libc, instead of the kernel. I think he's right. >> There is also one possibility that would be relatively simple to >> implement, and that is segmented stacks. Segmented stacks are >> discontiguous and the segments are allocated on demand. There are two >> drawbacks. A minor one is that there is an overhead of few >> instructions per function call. A major one is that it needs linker >> support, and currently only gold linker supports it. However, HelenOS >> can't be build with gold linker (I tried and it can't digest our >> linker script). Perhaps someone could fix that? > > It would certainly be interesting to explore this idea a little further. > Btw, can gold target all platforms needed by HelenOS? And if yes, is > this split stack feature supported on all of them? IIRC, it was only > implemented (perhaps on the gcc side) for x86. > Good point. I didn't think in terms of multiple architectures. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
