Date: Mon, 17 Apr 2000 22:07:51 +0400 (MSD) From: Dmitry Kim <jason@jsn.express.ru> To: freebsd-current@freebsd.org Subject: setrlimit(), break() and mmap() Message-ID: <200004171807.WAA20589@jsn.kmost.express.ru>
next in thread | raw e-mail | index | archive | help
hello, people,
i was playing with setrlimit(), break() and mmap() in freebsd 4.0 and
in CURRENT, and i have a couple of questions:
1. kernel code for break() syscall checks if the requested value for the
data segment size is more than RLIMIT_DATA, and, if yes, it just returns
ENOMEM. thus, the calling process receives ENOMEM even in case it is trying
to return some memory to the system; for example, if user process does
something like "alloc(100Mb); setrlimit(RLIMIT_DATA,&{1Mb,0}); free(50Mb)",
break() system call in the free() will fail, and no memory will be returned to
the system.
imho, the user process should always be allowed to return memory to the
system, no matter what. thus, in [o]break() we should 1) check if we the process
is trying to return some memory, and, if yes, let him in, and then 2) check
RLIMIT_DATA, VM_MAX_USER_ADDRESS and what ever else. or am i missing anything?
2. break() is not the only way for the process to ask the system for some
more memory. the user process can use mmap(NULL,..., MAP_ANON,...). for this
case, RLIMIT_DATA is never checked, and i did not find any way to limit the
amount of memory which is available to a specific process/user via
mmap( ...,MAP_ANON...,...). seems like just any user can eat up all the memory
in the system using mmap() instead of break() for his malloc/free library.
which would be definitely a Bad Thing :) or am i missing something?
would anyone please explain to me what is the purpose of having RLIMIT_DATA
if this limitation can be so easily worked around?
have a nice time of day,
jsn.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004171807.WAA20589>