Hello;
On 6/29/2017 8:23 AM, Shawn Webb wrote:
On Wed, Jun 28, 2017 at 06:32:38PM -0400, Shawn Webb wrote:
On Wed, Jun 28, 2017 at 04:02:37AM +0000, Konstantin Belousov wrote:
Author: kib
Date: Wed Jun 28 04:02:36 2017
New Revision: 320430
URL: https://svnweb.freebsd.org/changeset/base/320430
Log:
Treat the addr argument for mmap(2) request without MAP_FIXED flag as
a hint.
Right now, for non-fixed mmap(2) calls, addr is de-facto interpreted
as the absolute minimal address of the range where the mapping is
created. The VA allocator only allocates in the range [addr,
VM_MAXUSER_ADDRESS]. This is too restrictive, the mmap(2) call might
unduly fail if there is no free addresses above addr but a lot of
usable space below it.
Lift this implementation limitation by allocating VA in two passes.
First, try to allocate above addr, as before. If that fails, do the
second pass with less restrictive constraints for the start of
allocation by specifying minimal allocation address at the max bss
end, if this limit is less than addr.
One important case where this change makes a difference is the
allocation of the stacks for new threads in libthr. Under some
configuration conditions, libthr tries to hint kernel to reuse the
main thread stack grow area for the new stacks. This cannot work by
design now after grow area is converted to stack, and there is no
unallocated VA above the main stack. Interpreting requested stack
base address as the hint provides compatibility with old libthr and
with (mis-)configured current libthr.
Reviewed by: alc
Tested by: dim (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Modified:
head/sys/vm/vm_map.c
head/sys/vm/vm_map.h
head/sys/vm/vm_mmap.c
Hey Kostik,
This commit breaks both xorg and shutting down/rebooting. Reverting this
commit makes my laptop happy again.
Thnking out loud: would these issues arise due to HardenedBSD using
SafeStack, which relies on libthr's stack code?
I haven't been looking at SafeStack lately but unless HardenedBSD took
the FreeBSD-specific code from EPFL and did some real work on it, there
is little chance it does its work well.
Pedro.
ps. I would guess Oliver knows about the EPFL code since he did some
review on github.
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
