Nick Piggin wrote: > I see no reason why they couldn't both go in. In fact, having an mmap > flag for > adding guard regions around vmas (and perhaps eg. a system-wide / > per-process > option for stack) could almost go in tomorrow. This would have to be flexible, though. For thread stacks, at least, the programmer is able to specify the size of the guard area. It can be arbitrarily large. Also, consider IA-64. Here we have two stacks. We allocate them with one mmap call and put the guard somewhere in the middle (the optimal ratio of CPU and register stack size is yet to be determined) and have the stack grow toward each other. This results into three VMAs in the moment. Anything which results on more VMAs obviously isn't good. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Attachment:
signature.asc
Description: OpenPGP digital signature
- References:
- [patch 00/14] remap_file_pages protection support
- From: [email protected]
- Re: [patch 00/14] remap_file_pages protection support
- From: Nick Piggin <[email protected]>
- Re: [patch 00/14] remap_file_pages protection support
- From: Blaisorblade <[email protected]>
- Re: [patch 00/14] remap_file_pages protection support
- From: Nick Piggin <[email protected]>
- [patch 00/14] remap_file_pages protection support
- Prev by Date: Re: [PATCH 0/2][RFC] New version of shared page tables
- Next by Date: Re: [PATCH 10/13: eCryptfs] Mmap operations
- Previous by thread: Re: [patch 00/14] remap_file_pages protection support
- Next by thread: Re: [patch 00/14] remap_file_pages protection support
- Index(es):