(unknown charset) Re: sbrk(2) broken

Kostik Belousov wrote:
> On Fri, Jan 04, 2008 at 09:11:33AM -0500, Skip Ford wrote:
> > Kostik Belousov wrote:
> > > On Fri, Jan 04, 2008 at 08:54:38AM -0500, Skip Ford wrote:
> > > > Robert Watson wrote:
> > > > > On Fri, 4 Jan 2008, Dag-Erling Smørgrav wrote:
> > > > > >Robert Watson <rwatson_at_FreeBSD.org> writes:
> > > > > >>The right answer is presumably to introduce a new LIMIT_SWAP, which
> > > > > >>limits the allocation of anonymous memory by processes, and size it to
> > > > > >>something like 90% of swap space by default.
> > > > > >
> > > > > >Not a good solution on its own.  You need a per-process limit as well, 
> > > > > >otherwise a malloc() bomb will still cause other processes to fail 
> > > > > >randomly.
> > > > > 
> > > > > That was what I had in mind, the above should read RLIMIT_SWAP.
> > > > 
> > > > Are you referring to the implementation of RLIMIT_SWAP in the
> > > > overcommit-disable patch at:
> > > > 
> > > > http://people.freebsd.org/~kib/overcommit/index.html
> > > > 
> > > > ...or some other as yet unwritten implementation?  That patch doesn't
> > > > currently do 90% of swap but easily can.  That's been available for almost 3
> > > > years now.  I tested it at one point but not lately and it never went into
> > > > production.  Do you, and others, have a problem with that implementation?
> > 
> > > What you mean by "do 90% of swap" ?
> > 
> > I was referring only to what Robert said above, that he thinks RLIMIT_SWAP
> > should limit anon memory size to ~90% of swap by default.  Your patch,
> > last I looked, limits it to 100% of swap by design but could be easily
> > changed I think.
> 
> Ok. The patch really imposes two kind of limits:
> - the total amount of anon memory that could be allocated in the whole
>   system (this is what I called "disabling overcommit")
> - per-user RLIMIT_SWAP limit, that account the allocation by the uid. This
>   has some obvious problems with setuid(2) syscall. AFAIR, I ended up
>   not moving the accounted numbers to the new uid.
> 
> Both limits can be turned on/off independently.

Independently, but using the same sysctl knob which seems a bit awkward.

> May be, time to revive it.

The concensus in this thread seems to be that a per-process limit needs to
be implemented rather than, or in addition to, the per-uid limit you
already have.

-- 
Skip