Date: Fri, 6 Apr 2001 17:26:41 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Cc: arch@FreeBSD.ORG, bde@zeta.org.au, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Subject: Re: Mmap(2) should start just below stack (was: Re: Bumping up {MAX,DFL}*SIZ in i386) Message-ID: <200104070026.f370QfY50900@earth.backplane.com> References: <200103191056.f2JAuox00630@rina.r.dl.itc.u-tokyo.ac.jp> <Pine.BSF.4.21.0103201350200.41190-100000@besplex.bde.org> <200103230517.f2N5HXx08605@rina.r.dl.itc.u-tokyo.ac.jp> <200104050506.f3556Xw28400@rina.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
:I propose a solution against that problem by allocating the space just :below the stack of a process for mmap(2), as depicted below: : :| Process Stack | :+--------------------+ down to 3GB - max of RLIMIT_STACK :|Reserved for Process| :| Stack | :+--------------------+ 3GB - max of RLIMIT_STACK :| Mmap(2)ed space | :| (mmap(2), dynamic | This may be fragmented. :| linker, shared | :| objects, etc) | :+--------------------+ down to end of bss + max of RLIMIT_DATA :| Mmap(2) Heap | :+--------------------+ end of bss + max of RLIMIT_DATA :|Reserved for Malloc | :+--------------------+ up to end of bss + max of RLIMIT_DATA (break) :| Malloc(3) Heap | : :As the end of bss + max of RLIMIT_DATA gets less likely to cross over :mapped regions, we can provide much better flexibility of memory usage :... :Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> Hmm. Well, I like the idea of allocating from the end of the stack downwards a whole lot better then the idea of allocating from the end of RLIMIT_DATA upwards, but we have an issue in both cases that we have to deal with. suid-root programs often adjust resources upwards in order to avoid potential root compromises due to allocation failures at just the wrong time (coupled with a badly written program). Most commonly this means RLIMIT_DATA will be increased and, of course, many programs will also increase RLIMIT_DATA. However, the same problem with suid-root programs exists for RLIMIT_STACK as well. So using a RLIMIT_STACK based solution instead of RLIMIT_DATA only partially solves the problem. We also have a similar issue with fork(). Process A fork()'s and adjusts the resource limits for the child process downward or upward. -- One thing to note is that anonymous memory can trivially be allocated with mmap(), and will end up in the mmap space rather then the DATA/RSS space. Thus we have a potential solution that does not require any kernel modifications at all - use mmap() to allocate memory. Of course, at the moment, programs that allocate huge amounts of memory with malloc() would have to be aware of this fact to take advantage of it. I don't know what the correct solution is, but I am leary of making the mmap() space relative to user-adjustable resources. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104070026.f370QfY50900>