History log of /freebsd/sys/vm/vm_mmap.c (Results 76 – 100 of 774)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 01d4e214 05-Oct-2018 Glen Barber <gjb@FreeBSD.org>

MFH r338661 through r339200.

Sponsored by: The FreeBSD Foundation


# ce44d808 27-Sep-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r338731 through r338987.


# 2554f86a 18-Sep-2018 Mateusz Guzik <mjg@FreeBSD.org>

vm: stop taking proc lock in mmap to satisfy racct if it is disabled

Limits can be safely obtained with lim_cur from the thread. racct is compiled
in but disabled by default. Note that racct enablem

vm: stop taking proc lock in mmap to satisfy racct if it is disabled

Limits can be safely obtained with lim_cur from the thread. racct is compiled
in but disabled by default. Note that racct enablement is a boot-only tunable.

This eliminates second most common place of taking the lock while pkg building.

While here don't take the lock in mlockall either.

Reviewed by: kib
Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D17210

show more ...


# 14b841d4 11-Aug-2018 Kyle Evans <kevans@FreeBSD.org>

MFH @ r337607, in preparation for boarding


# bbd7a929 04-Aug-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r336870 through r337285, and resolve conflicts.


# 6e1d2cf6 31-Jul-2018 Konstantin Belousov <kib@FreeBSD.org>

For compat32, emulate the same wraparound check as occurs on the real
ILP32 system.

Reported by and discussed with: asomers
PR: 230162
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differen

For compat32, emulate the same wraparound check as occurs on the real
ILP32 system.

Reported by and discussed with: asomers
PR: 230162
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D16525

show more ...


Revision tags: release/11.2.0
# 3e7cb27c 04-Jun-2018 Alan Cox <alc@FreeBSD.org>

Use a single, consistent approach to returning success versus failure in
vm_map_madvise(). Previously, vm_map_madvise() used a traditional Unix-
style "return (0);" to indicate success in the common

Use a single, consistent approach to returning success versus failure in
vm_map_madvise(). Previously, vm_map_madvise() used a traditional Unix-
style "return (0);" to indicate success in the common case, but Mach-
style return values in the edge cases. Since KERN_SUCCESS equals zero,
the only problem with this inconsistency was stylistic. vm_map_madvise()
has exactly two callers in the entire source tree, and only one of them
cares about the return value. That caller, kern_madvise(), can be
simplified if vm_map_madvise() consistently uses Unix-style return
values.

Since vm_map_madvise() uses the variable modify_map as a Boolean, make it
one.

Eliminate a redundant error check from kern_madvise(). Add a comment
explaining where the check is performed.

Explicitly note that exec_release_args_kva() doesn't care about
vm_map_madvise()'s return value. Since MADV_FREE is passed as the
behavior, the return value will always be zero.

Reviewed by: kib, markj
MFC after: 7 days

show more ...


# 633d3b1c 02-Jun-2018 Konstantin Belousov <kib@FreeBSD.org>

Only check for MAP_32BIT when available.

Reported by: mmacy
Sponsored by: The FreeBSD Foundation
MFC after: 10 days


# 60221a57 01-Jun-2018 Alan Cox <alc@FreeBSD.org>

Only a small subset of mmap(2)'s flags should be used in combination with
the flag MAP_GUARD. Rather than enumerating the flags that are not
allowed, enumerate the flags that are allowed. The list

Only a small subset of mmap(2)'s flags should be used in combination with
the flag MAP_GUARD. Rather than enumerating the flags that are not
allowed, enumerate the flags that are allowed. The list of allowed flags
is much shorter and less likely to change. (As an aside, one of the
previously enumerated flags, MAP_PREFAULT, was not even a legal flag for
mmap(2). However, because of an earlier check within kern_mmap(), this
misuse of MAP_PREFAULT was harmless.)

Reviewed by: kib
MFC after: 10 days

show more ...


# 6469bdcd 06-Apr-2018 Brooks Davis <brooks@FreeBSD.org>

Move most of the contents of opt_compat.h to opt_global.h.

opt_compat.h is mentioned in nearly 180 files. In-progress network
driver compabibility improvements may add over 100 more so this is
close

Move most of the contents of opt_compat.h to opt_global.h.

opt_compat.h is mentioned in nearly 180 files. In-progress network
driver compabibility improvements may add over 100 more so this is
closer to "just about everywhere" than "only some files" per the
guidance in sys/conf/options.

Keep COMPAT_LINUX32 in opt_compat.h as it is confined to a subset of
sys/compat/linux/*.c. A fake _COMPAT_LINUX option ensure opt_compat.h
is created on all architectures.

Move COMPAT_LINUXKPI to opt_dontuse.h as it is only used to control the
set of compiled files.

Reviewed by: kib, cem, jhb, jtl
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D14941

show more ...


# e958ad4c 12-Feb-2018 Jeff Roberson <jeff@FreeBSD.org>

Make v_wire_count a per-cpu counter(9) counter. This eliminates a
significant source of cache line contention from vm_page_alloc(). Use
accessors and vm_page_unwire_noq() so that the mechanism can

Make v_wire_count a per-cpu counter(9) counter. This eliminates a
significant source of cache line contention from vm_page_alloc(). Use
accessors and vm_page_unwire_noq() so that the mechanism can be easily
changed in the future.

Reviewed by: markj
Discussed with: kib, glebius
Tested by: pho (earlier version)
Sponsored by: Netflix, Dell/EMC Isilon
Differential Revision: https://reviews.freebsd.org/D14273

show more ...


# 1c5196c3 20-Jan-2018 Konstantin Belousov <kib@FreeBSD.org>

Assign map->header values to avoid boundary checks.

In several places, entry start and end field are checked, after
excluding the possibility that the entry is map->header. By assigning
max and min

Assign map->header values to avoid boundary checks.

In several places, entry start and end field are checked, after
excluding the possibility that the entry is map->header. By assigning
max and min values to the start and end fields of map->header in
vm_map_init, the explicit map->header checks become unnecessary.

Submitted by: Doug Moore <dougm@rice.edu>
Reviewed by: alc, kib, markj (previous version)
Tested by: pho (previous version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D13735

show more ...


# 82725ba9 23-Nov-2017 Hans Petter Selasky <hselasky@FreeBSD.org>

Merge ^/head r325999 through r326131.


# 51369649 20-Nov-2017 Pedro F. Giffuni <pfg@FreeBSD.org>

sys: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 3-Clause license.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for

sys: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 3-Clause license.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.

show more ...


# f8190300 10-Nov-2017 Hans Petter Selasky <hselasky@FreeBSD.org>

Merge ^/head r325505 through r325662.


# bd0e1beb 08-Nov-2017 Mark Johnston <markj@FreeBSD.org>

Correct the type of foff.

No functional change intended.

Github PR: 124
Submitted by: Wuyang Chung <wuyang.m.chung@outlook.com>
MFC after: 1 week


Revision tags: release/10.4.0
# 531c2d7a 24-Jul-2017 Enji Cooper <ngie@FreeBSD.org>

MFhead@r320180


# bca9d05f 23-Jul-2017 Hans Petter Selasky <hselasky@FreeBSD.org>

Merge ^/head r319973 through 321382.


Revision tags: release/11.1.0
# f6e653bb 02-Jul-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r320398 through r320572.


# 6a97a3f7 28-Jun-2017 Konstantin Belousov <kib@FreeBSD.org>

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

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

show more ...


# a3604b95 27-Jun-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r320042 through r320397.


# 19bd0d9c 24-Jun-2017 Konstantin Belousov <kib@FreeBSD.org>

Implement address space guards.

Guard, requested by the MAP_GUARD mmap(2) flag, prevents the reuse of
the allocated address space, but does not allow instantiation of the
pages in the range. It is

Implement address space guards.

Guard, requested by the MAP_GUARD mmap(2) flag, prevents the reuse of
the allocated address space, but does not allow instantiation of the
pages in the range. It is useful for more explicit support for usual
two-stage reserve then commit allocators, since it prevents accidental
instantiation of the mapping, e.g. by mprotect(2).

Use guards to reimplement stack grow code. Explicitely track stack
grow area with the guard, including the stack guard page. On stack
grow, trivial shift of the guard map entry and stack map entry limits
makes the stack expansion. Move the code to detect stack grow and
call vm_map_growstack(), from vm_fault() into vm_map_lookup().

As result, it is impossible to get random mapping to occur in the
stack grow area, or to overlap the stack guard page.

Enable stack guard page by default.

Reviewed by: alc, markj
Man page update reviewed by: alc, bjk, emaste, markj, pho
Tested by: pho, Qualys
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D11306 (man pages)

show more ...


# 46dc8e9d 30-Mar-2017 Dmitry Chagin <dchagin@FreeBSD.org>

Add kern_mincore() helper for micore() syscall.

Suggested by: kib@
Reviewed by: kib@
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D10143


# d1780e8d 14-Mar-2017 Konstantin Belousov <kib@FreeBSD.org>

Use atop() instead of OFF_TO_IDX() for convertion of addresses or
addresses offsets, as intended.

Suggested and reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks


# 348238db 01-Mar-2017 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r314420 through r314481.


12345678910>>...31