[Webkit-unassigned] [Bug 65766] [GTK] OSAllocator::reserveUncommitted should not commit physical memory

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=65766





--- Comment #14 from Uli Schlachter <psychon at znc.in>  2012-09-17 12:40:47 PST ---
(In reply to comment #13)
> (In reply to comment #12)
> > (From update of attachment 164321 [details] [details])
> > This looks great, do you happen to have any knowledge of the BSD VM system, and whether this fix may apply? – OpenBSD have the same problem (see https://bugs.webkit.org/show_bug.cgi?id=61137) I'm wondering if the #if guard should include OS(OPENBSD), OS(NETBSD) and/or OS(FREEBSD) in addition to OS(LINUX).
> 
> From discussions i had with some of our VM devs, this wont work on OpenBSD - ie will blow at runtime, and apparently will throw away all the security measures (address space randomization and all). Don't ask me why, i'm just the messenger, and i don't understand how this whole stuff works.

I doubt that alot. The only thing that changes is that instead of asking for read-write-exec it now asks for "no access" memory. It doesn't dictate the virtual address of the memory block. So IMHO this shouldn't affect ASLR, but I won't ask you why it does affect it. :-)

> As for bug 61137, it's just workarounding the fact that pre-allocating 1Gb at startup when ulimit -m is 512Mb will directly blow up. So even if we had a 'mechanism to allocate VM without committing the physical pages up front' i think this wouldnt work.

"ulimit -m" limits the memory size. "ulimit -v" limits virtual memory. This code tries to reserve virtual memory without getting any "real" memory for it, so the 512 MiB limit on ulimit -m shouldn't matter (yet). In theory. So, from my understanding, this shouldn't hit the "ulimit -m" limit until it actually starts using that memory.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.