On Thu, Oct 06, 2016 at 11:39:49AM -0400, Ted Unangst wrote:
> Raimo Niskanen wrote:
> > On Wed, Oct 05, 2016 at 12:34:42PM -0400, Ted Unangst wrote:
> > > If somebody writes a C program that demonstrates the problem, I'm happy to
> > > take a look. I'm not installing erlang.
> > 
> > It has been ages since I wrote a C program from scratch, but here goes:
> 
> Thanks. That wasn't so bad, was it? :)

No, I might even have kind of liked it ;-)

> 
> > And the symptom would be that the ulimit -m limit is not immediately
> > enforced.  The question is if that is a problem?  Or rather if I can use
> > the ulimit -m limit to prevent a process from taking all memory since I
> > need to set a large ulimit -d size to do clever address comparision tricks
> > in the Erlang VM.
> 
> Ah, indeed. So ulimit -m doesn't do anything any more. I'm not sure when it
> stopped, but the man page reflects ancient history. Sorry about that.
> Unfortunately, it's not easy to make PROT_NONE stop counting. After all, it
> may have been mapped read/write, and modified, then mapped none, but we can't
> discard the page.

So a program may count on the content persisting after that manouver...
Ugh!

I am quite happy with PROT_NONE not counting, but are you saying that if
you would start counting PROT_READ|PROT_WRITE you would have to also count
PROT_NONE, which would make the trick of allocating a large PROT_NONE block
just for its address space not usable.

And the manual page is wrong in claiming that ulimit -m takes effect when
the system gets low on memory?

So the only memory limit that is enforced is ulimit -d?

Bummer.

What I guess we (VM tricksters) would really want is MAP_NORESERVE...

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Reply via email to