Re: sbrk(2) broken

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?
> > Oh, I thought that I was the sole user of the patch. What problems did you
> > encountered while testing it ?
> 
> Nope, there are two of us. :-)
> 
> I don't remember encountering problems.  I never put it into production
> because maintaining it in a local branch was beyond my ability.  I just didn't
> know enough to know what it did and didn't do, or how it would have to be
> modified to work with future changes.  I just didn't understand it enough
> to go with it and maintain it.
> 
> > 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.

May be, time to revive it.