Re: Getting rid of SHMMAX/SHMALL ?

[Andi Kleen <ak@suse.de>]

On Thu, Aug 04, 2005 at 05:20:40PM +0300, Matti Aarnio wrote:
> SHM resources are non-swappable, thus I would not by default

Not true.

> let user programs go and allocate very much SHM spaces at all.
> Such is usually spelled as: "denial-of-service-attack"
> For that reason I would not raise builtin defaults either.

It is equivalent to allocating anymous memory in programs.

In theory you could limit it for each user by RLIMIT_NPROC*RLIMIT_AS,
but in practice that would be usually
If Linux ever gets a "max memory total used per user" rlimit it may make
sense to limit the shm growth caused by them to that, but that is not
there yet. In addition I want to point out that there are a zillion
of subsystems which can be used to allocate quite a lot of memory
(e.g. fill the socket buffers of a few hundred sockets)
So far nobody knows how to limit all of these and it's probably too hard
to do. The general wisdom is that if you want strong isolation like
that use a virtualized environment.

> > 
> > I think we should just get rid of the per process limit and keep
> > the global limit, but make it auto tuning based on available memory.
> 
> Err...  No thanks!   I would prefer to have even finer grained control
> of how much SHM somebody can allocate.  For normal user the value
> might be zero, but for users in a group "SHM1" there could be a level
> of N MB, etc.  (Except that such mechanisms are rather complex...)

shmmni will stay, although the defaults will be larger. If you really
want you can lower it, but in practice it won't buy you much if anything.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/