Re: updating COMPAT_LINUX for linux 2.6.x support (take 2)

[Chuck Silvers <chuq%chuq.com@localhost>]

On Mon, Jun 07, 2010 at 07:48:06AM +1000, matthew green wrote:
> 
> > On Sat, Jun 05, 2010 at 01:02:12PM +1000, matthew green wrote:
> > > 
> > > >  - fix obreak() to honor RLIMIT_AS as well as RLIMIT_DATA.
> > > >    this will affect native processes as well as linux ones,
> > > >    but it seems appropriate.
> > > 
> > > if you're going to do this, you may as well just make RLIMIT_AS and
> > > RLIMIT_DATA refer to the same thing (and make that RLIMIT_AS.)
> > > 
> > > when implementing RLIMIT_AS i was confused about how these would
> > > interact, and clearly there was a problem. :)
> > > 
> > > there's also RLIMIT_STACK, but it has additional semantics that
> > > make it different to both _AS and _DATA, further adding to the
> > > confusion..
> > 
> > combining RLIMIT_AS and RLIMIT_DATA sounds confusing.
> > 
> > I looked at what linux does here: RLIMIT_DATA only affects brk(),
> > whereas RLIMIT_AS affects all mappings.  that's what we were trying
> > to do too, but I think we just put the check in the wrong place...
> > if we move it to uvm_map() instead of uvm_mmap(), that will catch
> > brk() and stack usage too.  let me try that and see what breaks.
> 
> yeah, that was my intent.
> 
> btw, linux also defaults to all of them being unlimited so their
> semantics aren't overly clear to me in the cases that matter...

ok, I looked into that and it's a bit messy because of how to count the stack.
there are three ways to look at it:

 (1) the actual map entries for the stack, which are always MAXSSIZ in size.
     not so useful.
 (2) the current value of RLIMIT_STACK.  more useful, but still eh.
 (2) the size of the portion of the stack that's actually been touched
     (vm->vm_ssize).  this sounds best, but that would imply that
     we should check against RLIMIT_AS every time we increase vm_ssize.
     maintenance of this field is nicely centralized in uvm_grow(),
     which even checks against RLIMIT_STACK and returns an indication of
     whether stack growth should be allowed.... which every caller ignores.
     sigh.


so, in the longer run I'll change uvm_grow() to return an errno
instead of 0/1, have it check RLIMIT_AS too, and change the callers
to look at the return value and generate SIGSEGV if it returns an error.
I'll save that for after I'm done with this linux stuff though.

-Chuck