Re: Ulimit Probrems with Linux

brian@nycrc.net
Fri, 21 Aug 1998 22:59:14 -0400

> On Fri, 21 Aug 1998 brian@nycrc.net wrote:
>
> > >From these tests I can only conclude that if you use malloc to allocate
> > buffers larger than 128k the problem will occur consistently. Even if
> > ulimit is set to 100 bytes an 8M segment is allocated somewhere. Generally
> > speaking, most code does not do this, however, this appears to be a case
> > where Apache does. Either there is a significant flaw in my thinking on
> > this or a flaw in the way linux is allocating memory. If it's the former,
> > well, apologies in advance. If it is the latter, I believe it must be
> > addressed since it creates a vulnerability that represents a serious bug.
>
> Right, as you mention mmap is the one doing some of the allocations.
>
> The allocations made by mmap() aren't getting counted against the data
> segment (and they aren't really part of it anyway). You will probably
> find that the reason some use it and not others has to do with the
> heuristic used by mmap() to figure out when it should and shouldn't use
> mmap() to allocate memory.
>
> Hmm. I would think a limit on the rss would do something, but it also
> doesn't appear to take mmap()ed segments into account even though they are
> counted as part of the rss.
>
> ulimit -v does though.
>
>
>
>
Hello,

I tried ulimit -v and it kept saying

ulimit: cannot raise limit: Invalid argument

I am running bash 1.14.7. I took a look at the source
and in bash-1.14.7/builtins/ulimit.def there is the
code segment

case u_MAX_VIRTUAL_MEM:
if (setting)
{
errno = EINVAL;
return ((RLIMTYPE)-1);
}
else
{
#if defined (HAVE_RESOURCE)
return (getmaxvm (mode));
#else /* !HAVE_RESOURCE */
errno = EINVAL;
return ((RLIMTYPE)-1);
#endif /* !HAVE_RESOURCE */
}

which tells me that if you are setting, the -v paramter
will always fail with EINVAL (Invalid argument).

I also experimented with ulimit -s and ulimit -m and the
ulimit -v value appears to be a sum of the ulimit -d and
ulimit -s arguments. Now I do not know if this is just
fluff added to bash because they hadn't finished coding
that part or they actually changed the maximum virtual
memory setting.

bash-2.02.1 appears to have a rewrite of this ulimit.def
file (haven't looked at that yet though) and I could always
write a wrapper that does the setrlimit and then execs
whatever I tell it to.

Do you know what equivalent setrlimit goes with ulimit -v.
I checked the manual page on setrlimit and there is an argument
for RLIMIT_DATA, RLIMIT_STACK, RLIMIT_RSS which correspond
to ulimit -d, -s, and -m but there is not one for ulimit -v.

I also noticed that allocation of data blocks larger than
128k would go into 0x400????? memory address space and the
blocks smaller than 0x804????? memory address space. So
they are definitely in different places. My question is
how come ulimit -d does not control both places.
The 0x400????? seems to tap out at about 8M and the
0x804????? is controlled via the ulimit -d. However, whats
the point of a ulimit -d if you can just allocate larger
blocks in a different memory area and have no affect on your
data size.

Brian Ackerman

-
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.altern.org/andrebalsa/doc/lkml-faq.html