lkml.org 
[lkml]   [2000]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory management...
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.208 / U:3.976 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site