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
