On Thu, 3 Aug 2000, Richard B. Johnson wrote:
> On Wed, 2 Aug 2000, Tigran Aivazian wrote:
>
> > On Wed, 2 Aug 2000, Richard B. Johnson wrote:
> > > So what did you expect? Now turn on user limits.
> >
> > did you actually try your own suggestion? Iwas rather puzzled by the fact
> > that turning on the user limits is obviously not enough. Or at least not
> > the obvious user limits (RLIMIT_DATA, RLIMIT_STACK, RLIMIT_RSS) but a
> > rather unobvious one - RLIMIT_AS. This is because malloc(3) uses not just
> > brk(2) system call (which honours RLIMIT_DATA) but
> > mmap(MAP_PRIVATE|MAP_ANONYMOUS) which honours RLIMIT_AS.
>
> No I did not. If the writer had said they he had found a way to bypass
> user limits then I would have been more receptive. However, merely
> submitting some code that will run the system out of memory and
> stating that it will lock up the system, left no hint that he was
> using user limits. Also, where did you find that he was using a
> special malloc()? DEFAULT_MMAP_THRESHOLD on glibc-2.0.6 that I have the
> source for is 128 * 1024. His code does not magically hit a boundary.
it does (probably due to a bug and not intentionally as his code looked
awful anyway). It keeps failing for a long time and then eventually hits a
very large old_mmap() request which succeeds and that lets him allocate 1G
(on my machine) unless you set RLIMIT_AS appropriately. Try it - although
now things are all clear so it is no longer interesting...
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:11 EST