Revision tags: vendor/xz/5.4.5 |
|
#
29363fb4 |
| 23-Nov-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove ancient SCCS tags.
Remove ancient SCCS tags from the tree, automated scripting, with two minor fixup to keep things compiling. All the common forms in the tree were removed with a perl s
sys: Remove ancient SCCS tags.
Remove ancient SCCS tags from the tree, automated scripting, with two minor fixup to keep things compiling. All the common forms in the tree were removed with a perl script.
Sponsored by: Netflix
show more ...
|
Revision tags: vendor/llvm-project/llvmorg-17.0.5-0-g98bfdac5ce82, vendor/unbound/1.19.0, vendor/sqlite3/sqlite-3440000, release/14.0.0, vendor/llvm-project/llvmorg-17.0.3-0-g888437e1b600, vendor/bsddialog/1.0, vendor/llvm-project/llvmorg-17.0.2-0-gb2417f51dbbd, vendor/openssh/9.5p1, vendor/llvm-project/llvmorg-17.0.1-25-g098e653a5bed, vendor/nvi/2.2.1, vendor/openssl/3.0.11, vendor/sqlite3/sqlite-3430100, vendor/unbound/1.18.0, vendor/NetBSD/bmake/20230909, vendor/openssl/1.1.1w, vendor/llvm-project/llvmorg-17.0.0-rc4-10-g0176e8729ea4, vendor/file/5.45, vendor/llvm-project/llvmorg-17.0.0-rc3-79-ga612cb0b81d8, vendor/krb5/1.21.2, vendor/unifdef/2.12, vendor/unifdef/2.11, 2023.08.19-b34f66deb02e188104, vendor/zlib/1.3 |
|
#
95ee2897 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: two-line .h pattern
Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/
|
Revision tags: vendor/less/v643, vendor/NetBSD/libc-vis/20230813, vendor/openssh/9.4p1, vendor/device-tree/6.4, vendor/device-tree/6.3, vendor/device-tree/6.2, vendor/device-tree/6.1, vendor/krb5/1.21.1, vendor/xz/5.4.4, vendor/openssl/3.0.10, vendor/openssl/1.1.1v |
|
#
90049eab |
| 28-Jul-2023 |
Konstantin Belousov <kib@FreeBSD.org> |
vm_map_protect(): add VM_MAP_PROTECT_GROWSDOWN flag
which requests to propagate lowest stack segment protection to the grow gap. This seems to be required for Linux emulation.
Reported by: dchagin
vm_map_protect(): add VM_MAP_PROTECT_GROWSDOWN flag
which requests to propagate lowest stack segment protection to the grow gap. This seems to be required for Linux emulation.
Reported by: dchagin Reviewed by: alc, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D41099
show more ...
|
Revision tags: vendor/llvm-project/llvmorg-17-init-19311-gbc849e525f80, vendor/llvm-project/llvmorg-17-init-19304-gd0b54bb50e51 |
|
#
ba41b0de |
| 19-Jul-2023 |
Konstantin Belousov <kib@FreeBSD.org> |
Add vm_map_insert1(9)
The function returns the newly created entry. Use vm_map_insert1() in stack grow code to avoid gap entry re-lookup.
The comment update for vm_map_try_merge_entries() was sugge
Add vm_map_insert1(9)
The function returns the newly created entry. Use vm_map_insert1() in stack grow code to avoid gap entry re-lookup.
The comment update for vm_map_try_merge_entries() was suggested by dougm.
Suggested by: alc Reviewed by: alc, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D41099
show more ...
|
#
9da33e8d |
| 10-Aug-2023 |
Konstantin Belousov <kib@FreeBSD.org> |
Update comment describing struct vm_map
There is no list connecting all entries any more, and correspondingly no order on the list entries.
Reviewed by: dougm Sponsored by: The FreeBSD Foundation M
Update comment describing struct vm_map
There is no list connecting all entries any more, and correspondingly no order on the list entries.
Reviewed by: dougm Sponsored by: The FreeBSD Foundation MFC after: 3 days Differential revision: https://reviews.freebsd.org/D41405
show more ...
|
Revision tags: vendor/openssh/9.3p2, vendor/lua/5.4.6, vendor/NetBSD/bmake/20230622, vendor/openpam/XIMENIA, vendor/heimdal/7.8.0-2023-06-10-f62e2f278, vendor/openssl/3.0.9, vendor/llvm-project/llvmorg-16.0.6-0-g7cbf1a259152, vendor/ntp/4.2.8p17, vendor/llvm-project/llvmorg-16.0.5-0-g185b81e034ba, vendor/spleen/2.0.0, vendor/ntp/4.2.8p16, vendor/openssl/1.1.1u, vendor/sqlite3/sqlite-3420000, vendor/bc/6.6.0, vendor/llvm-project/llvmorg-16.0.4-0-gae42196bc493, vendor/NetBSD/bmake/20230510, vendor/xz/5.4.3, vendor/tcpdump/4.99.4 |
|
#
d0e4e53e |
| 09-May-2023 |
Mark Johnston <markj@FreeBSD.org> |
vm_map: Add a macro to fetch a map entry's split boundary index
The resulting code is a bit more concise. No functional change intended.
Reviewed by: alc, dougm, kib MFC after: 1 week Differential
vm_map: Add a macro to fetch a map entry's split boundary index
The resulting code is a bit more concise. No functional change intended.
Reviewed by: alc, dougm, kib MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D41249
show more ...
|
#
21e45c30 |
| 19-Jul-2023 |
Konstantin Belousov <kib@FreeBSD.org> |
mmap(MAP_STACK): on stack grow, use original protection
If mprotect(2) changed protection in the bottom of the currently grown stack region, currently the changed protection would be used for the st
mmap(MAP_STACK): on stack grow, use original protection
If mprotect(2) changed protection in the bottom of the currently grown stack region, currently the changed protection would be used for the stack grow on next fault. This is arguably unexpected.
Store the original protection for the entry at mmap(2) time in the offset member of the gap vm_map_entry, and use it for protection of the grown stack region.
PR: 272585 Reported by: John F. Carr <jfc@mit.edu> Reviewed by: alc, markj Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D41089
show more ...
|
#
d8e6f494 |
| 23-Jun-2023 |
Alan Cox <alc@FreeBSD.org> |
vm: Fix anonymous memory clustering under ASLR
By default, our ASLR implementation is supposed to cluster anonymous memory allocations, unless the application's mmap(..., MAP_ANON, ...) call include
vm: Fix anonymous memory clustering under ASLR
By default, our ASLR implementation is supposed to cluster anonymous memory allocations, unless the application's mmap(..., MAP_ANON, ...) call included a non-zero address hint. Unfortunately, clustering never occurred because kern_mmap() always replaced the given address hint when it was zero. So, the ASLR implementation always believed that a non-zero hint had been provided and randomized the mapping's location in the address space. To fix this problem, I'm pushing down the point at which we convert a hint of zero to the minimum allocatable address from kern_mmap() to vm_map_find_min().
Reviewed by: kib MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D40743
show more ...
|
Revision tags: vendor/llvm-project/llvmorg-16.0.3-0-gda3cd333bea5, vendor/ldns/1.8.3, vendor/spleen/1.9.3, vendor/libpcap/1.10.4, vendor/spleen/1.6.0, vendor/less/v632, vendor/bc/6.5.0, vendor/libfido2/1.13.0, vendor/libfido2/1.12.0, vendor/libfido2/1.11.0, vendor/libfido2/1.10.0, vendor/libfido2/1.9.0, vendor/NetBSD/bmake/20230414, vendor/llvm-project/llvmorg-16.0.2-0-g18ddebe1a1a9, vendor/libcbor/0.10.2, vendor/tzcode/tzcode2023c, vendor/tzcode/tzcode2023b, vendor/tzcode/tzcode2023a, vendor/sqlite3/sqlite-3410200, vendor/llvm-project/llvmorg-16.0.1-0-gcd89023f7979, release/13.2.0, vendor/llvm-project/llvmorg-16.0.0-45-g42d1b276f779, vendor/llvm-project/llvmorg-16.0.0-0-g08d094a0e457, vendor/tzdata/tzdata2023c, vendor/libpcap/1.10.3, vendor/opencsd/v1.4.0, vendor/arm-optimized-routines/v23.01, vendor/tzdata/tzdata2023b, vendor/tzdata/tzdata2023a, vendor/xz/5.4.2, vendor/openssh/9.3p1, vendor/openssl/3.0.8, vendor/bc/6.4.0, vendor/sqlite3/sqlite-3410000, vendor/bc/6.3.1, vendor/bearssl/20230220, vendor/zlib/1.2.13, vendor/llvm-project/llvmorg-16.0.0-rc2-10-g073506d8c15c, vendor/llvm-project/llvmorg-16-init-18548-gb0daacf58f41, vendor/NetBSD/bmake/20230208, vendor/byacc/20230201, vendor/openssl/1.1.1t, vendor/NetBSD/libedit/2023-01-06, vendor/openssh/9.2p1, vendor/tcsh/6.24.07, vendor/bc/6.2.2, vendor/bc/6.2.1, vendor/bc/6.2.0, vendor/bc/6.1.0, vendor/bc/6.0.4, vendor/NetBSD/bmake/20230126, vendor/Juniper/libxo/1.6.0, vendor/zstd/1.5.2, vendor/xz/5.4.1, vendor/sendmail/8.17.1, vendor/llvm-project/llvmorg-15.0.7-0-g8dfdcc7b7bf6, vendor/heimdal/7.8.0, vendor/sqlite3/sqlite-3400100, vendor/xz/5.4.0, vendor/tzcode/tzcode2022g, vendor/tzcode/tzcode2022f, vendor/tzcode/tzcode2022e, vendor/tzcode/tzcode2022d, vendor/xz/5.2.9, vendor/llvm-project/llvmorg-15.0.6-0-g088f33605d8a, vendor/tzdata/tzdata2022g, release/12.4.0, vendor/sqlite3/sqlite-3400000, vendor/expat/2.5.0, vendor/xz/5.2.8, vendor/device-tree/6.0, vendor/device-tree/5.19, vendor/openssl/1.1.1s, vendor/wireguard-tools/v1.0.20210914, vendor/tzdata/tzdata2022f, vendor/acpica/20221020, vendor/unbound/1.17.0, vendor/llvm-project/llvmorg-15.0.2-10-gf3c5289e7846, vendor/llvm-project/llvmorg-15.0.2-0-g4bd3f3759259, vendor/llvm-project/llvmorg-15.0.1-0-gb73d2c8c720a, vendor/tzdata/tzdata2022e, vendor/openssh/9.1p1, vendor/unbound/1.16.3, vendor/bsddialog/0.4, vendor/tzdata/tzdata2022d, vendor/file/5.43, vendor/expat/2.4.9, vendor/sqlite3/sqlite-3390300, vendor/llvm-project/llvmorg-15.0.0-9-g1c73596d3454, vendor/llvm-project/llvmorg-15.0.0-0-g4ba6a9c9f65b, vendor/less/v608, vendor/bsddialog/0.3, vendor/lua/5.4.4, vendor/lua/5.4.3, vendor/sqlite3/sqlite-3390200, vendor/bc/6.0.2, verndor/bc/6.0.2, vendor/dhcpcd/9.4.1, vendor/tzcode/tzcode2022c, vendor/tzcode/unsplit, vendor/tzdata/tzdata2022c, vendor/llvm-project/llvmorg-15.0.0-rc2-40-gfbd2950d8d0d, vendor/tzdata/tzdata2022b, vendor/arm-optimized-routines/20220210-89ca9c3, vendor/device-tree/5.18, vendor/device-tree/5.17, vendor/device-tree/5.16, vendor/device-tree/5.15, vendor/device-tree/5.14, vendor/unbound/1.16.2, vendor/llvm-project/llvmorg-15-init-17826-g1f8ae9d7e7e4, vendor/llvm-project/llvmorg-15-init-17827-gd77882e66779, vendor/NetBSD/bmake/20220726, vendor/NetBSD/bmake/20220724, vendor/llvm-project/llvmorg-15-init-17485-ga3e38b4a206b, vendor/llvm-project/llvmorg-15-init-16436-g18a6ab5b8d1f, vendor/unbound/1.16.1, vendor/sqlite3/sqlite-3390000, vendor/openssl/1.1.1q, vendor/file/5.42, vendor/llvm-project/llvmorg-15-init-15358-g53dc0f107877, vendor/openssl/1.1.1p, vendor/bc/5.3.3, vendor/bc/5.3.2, vendor/llvm-project/llvmorg-14.0.5-0-gc12386ae247c, vendor/bc/5.3.1, vendor/bc/5.3.0, vendor/unbound/1.16.0, vendor/llvm-project/llvmorg-14.0.4-0-g29f1039a7285 |
|
#
361971fb |
| 02-Jun-2022 |
Kornel Dulęba <kd@FreeBSD.org> |
Rework how shared page related data is stored
Store the shared page address in struct vmspace. Also instead of storing absolute addresses of various shared page segments save their offsets with resp
Rework how shared page related data is stored
Store the shared page address in struct vmspace. Also instead of storing absolute addresses of various shared page segments save their offsets with respect to the shared page address. This will be more useful when the shared page address is randomized.
Approved by: mw(mentor) Sponsored by: Stormshield Obtained from: Semihalf Reviewed by: kib Differential Revision: https://reviews.freebsd.org/D35393
show more ...
|
Revision tags: vendor/sqlite3/sqlite-3380500, release/13.1.0, upstream/13.1.0, vendor/bc/5.2.5, vendor/openssl/1.1.1o, vendor/llvm-project/llvmorg-14.0.2-0-g0e27d08cdeb3, vendor/llvm-project/llvmorg-14.0.3-0-g1f9140064dfb, vendor/NetBSD/bmake/20220418, vendor/bearssl/20220418, vendor/bc/5.2.4, vendor/NetBSD/libedit/2022-04-11, vendor/openssh/9.0p1, vendor/NetBSD/bmake/20220330, vendor/acpica/20220331, vendor/zlib/1.2.12, vendor/llvm-project/llvmorg-14.0.0-2-g3f43d803382d, vendor/heimdal/7.7.0, vendor/expat/2.4.7, vendor/llvm-project/llvmorg-14.0.0-rc4-2-gadd3ab7f4c8a, vendor/tzdata/tzdata2022a, vendor/openssl/1.1.1n, vendor/bsddialog/0.2, vendor/libcxxrt/2022-03-09-fd484be8d1e94a1fcf6bc5c67e5c07b65ada19b6, vendor/bc/5.2.3, vendor/llvm-project/llvmorg-14.0.0-rc2-12-g09546e1b5103, vendor/expat/2.4.6, vendor/openssh/8.9p1, vendor/llvm-project/llvmorg-13.0.1-0-g75e33f71c2da, vendor/llvm-project/llvmorg-14.0.0-rc1-74-g4dc3cb8e3255, vendor/unbound/1.15.0, vendor/NetBSD/bmake/20220208, vendor/bc/5.2.2, vendor/NetBSD/bmake/20220204, vendor/llvm-project/llvmorg-14-init-18315-g190be5457c90, vendor/llvm-project/llvmorg-14-init-18294-gdb01b123d012, vendor/terminus/terminus-font-4.49.1, vendor/bsddialog/0.1, vendor/llvm-project/llvmorg-14-init-17616-g024a1fab5c35, vendor/dma/2022-01-27, vendor/ena-com/2.5.0 |
|
#
1811c1e9 |
| 17-Jan-2022 |
Mark Johnston <markj@FreeBSD.org> |
exec: Reimplement stack address randomization
The approach taken by the stack gap implementation was to insert a random gap between the top of the fixed stack mapping and the true top of the main pr
exec: Reimplement stack address randomization
The approach taken by the stack gap implementation was to insert a random gap between the top of the fixed stack mapping and the true top of the main process stack. This approach was chosen so as to avoid randomizing the previously fixed address of certain process metadata stored at the top of the stack, but had some shortcomings. In particular, mlockall(2) calls would wire the gap, bloating the process' memory usage, and RLIMIT_STACK included the size of the gap so small (< several MB) limits could not be used.
There is little value in storing each process' ps_strings at a fixed location, as only very old programs hard-code this address; consumers were converted decades ago to use a sysctl-based interface for this purpose. Thus, this change re-implements stack address randomization by simply breaking the convention of storing ps_strings at a fixed location, and randomizing the location of the entire stack mapping. This implementation is simpler and avoids the problems mentioned above, while being unlikely to break compatibility anywhere the default ASLR settings are used.
The kern.elfN.aslr.stack_gap sysctl is renamed to kern.elfN.aslr.stack, and is re-enabled by default.
PR: 260303 Reviewed by: kib Discussed with: emaste, mw MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D33704
show more ...
|
Revision tags: vendor/wpa/2.10, vendor/expat/2.4.3, vendor/sqlite3/sqlite-3370200, vendor/wpa/gb26f5c0fe, vendor/sqlite3/sqlite-3370100, vendor/file/5.41, vendor/llvm-project/llvmorg-14-init-13186-g0c553cc1af2e, vendor/bsddialog/0.0.2, vendor/NetBSD/bmake/20211212, vendor/openssl/1.1.1m, vendor/unbound/1.14.0, vendor/bsddialog/0.0.1, vendor/unbound/1.14.0rc1, vendor/llvm-project/llvmorg-14-init-11187-g222442ec2d71, release/12.3.0, upstream/12.3.0, vendor/wpa/g14ab4a816, vendor/bc/5.2.1, vendor/bc/5.2.0, vendor/bsddialog/2021-11-24, vendor/llvm-project/llvmorg-14-init-10223-g401b76fdf2b3, vendor/llvm-project/llvmorg-14-init-10186-gff7f2cfa959b, vendor/mandoc/1.14.6, vendor/openssh/8.8p1, vendor/ck/2021029, vendor/tzdata/tzdata2021e, vendor/tzdata/tzdata2021d |
|
#
889b56c8 |
| 13-Oct-2021 |
Dawid Gorecki <dgr@semihalf.com> |
setrlimit: Take stack gap into account.
Calling setrlimit with stack gap enabled and with low values of stack resource limit often caused the program to abort immediately after exiting the syscall.
setrlimit: Take stack gap into account.
Calling setrlimit with stack gap enabled and with low values of stack resource limit often caused the program to abort immediately after exiting the syscall. This happened due to the fact that the resource limit was calculated assuming that the stack started at sv_usrstack, while with stack gap enabled the stack is moved by a random number of bytes.
Save information about stack size in struct vmspace and adjust the rlim_cur value. If the rlim_cur and stack gap is bigger than rlim_max, then the value is truncated to rlim_max.
PR: 253208 Reviewed by: kib Obtained from: Semihalf Sponsored by: Stormshield MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D31516
show more ...
|
Revision tags: vendor/bc/5.1.1, vendor/bc/5.1.0, vendor/tzdata/tzdata2021c, vendor/libfido2/1.8.0, vendor/libcbor/0.8.0, vendor/acpica/20210930, vendor/llvm-project/llvmorg-13.0.0-0-gd7b669b3a303, vendor/llvm-project/llvmorg-13.0.0-rc4-0-gd7b669b3a303, vendor/tzdata/tzdata2021b, vendor/dma/2021-07-10, vendor/NetBSD/libedit/2021-09-10, vendor/bc/5.0.2, vendor/llvm-project/llvmorg-13.0.0-rc3-8-g08642a395f23, vendor/llvm-project/llvmorg-13.0.0-rc2-43-gf56129fe78d5, vendor/openssl/1.1.1l, vendor/openssh/8.7p1, vendor/llvm-project/llvmorg-13.0.0-rc1-97-g23ba3732246a, vendor/llvm-project/llvmorg-13.0.0-rc1-0-gd6974c010878, vendor/unbound/1.13.2, vendor/one-true-awk/0592de4a, vendor/acpica/20210730, vendor/llvm-project/llvmorg-13-init-16854-g6b2e4c5a58d7, vendor/llvm-project/llvmorg-12.0.1-0-gfed41342a82f, vendor/llvm-project/llvmorg-12.0.1-rc2-0-ge7dac564cd0e, vendor/llvm-project/llvmorg-13-init-16847-g88e66fa60ae5, vendor/less/v590, llvmorg-12.0.1-0-gfed41342a82f, vendor/one-true-awk/1e4bc42c53a1, vendor/device-tree/5.13, vendor/device-tree/5.12, vendor/NetBSD/bmake/20210621, vendor/ena-com/2.4.0, vendor/NetBSD/vis/20210621, llvmorg-12.0.1-rc2-0-ge7dac564cd0e, vendor/acpica/20210604, vendor/nvi/2.2.0-3bbdfe4, vendor/tcsh/6.22.04, vendor/bc/4.0.2, vendor/sqlite3/sqlite-3350500, vendor/less/v581.2, vendor/bc/4.0.1, vendor/openssh/8.6p1, vendor/openssh/8.5p1, vendor/llvm-project/llvmorg-12.0.0-0-gd28af7c654d8, vendor/less/v581, vendor/google/capsicum-test/ea66424d921bb393539b298c108a46edee5c3051, release/13.0.0, upstream/13.0.0, vendor/bc/4.0.0, vendor/acpica/20210331, vendor/NetBSD/libedit/2021-03-28, vendor/openssl/1.1.1k, vendor/device-tree/5.11, vendor/NetBSD/libedit/2020-07-10, vendor/libucl/20210314, vendor/bc/3.3.4, vendor/wpa/g9d9b42306541, vendor/tcsh/6.22.03-ceccc7f, bc/3.3.3, vendor/google/capsicum-test/20210302, vendor/dialog/1.3-20210117, vendor/ncurses/6.2-20210220, vendor/arm-optimized-routines/v21.02, vendor/libcxxrt/2021-02-18-8049924686b8414d8e652cbd2a52c763b48e8456, vendor/bc/bc-3.3.0, vendor/llvm-project/llvmorg-12.0.0-rc1-109-gd5d089bf08c9, vendor/llvm-project/llvmorg-12-init-17869-g8e464dd76bef, vendor/openssl/1.1.1j, vendor/google/capsicum-test/7707222b46abe52d18fd4fbb76115ffdb3e6f74b, vendor/openssh/8.4p1, vendor/openssh/8.3p1, vendor/openssh/8.2p1, vendor/openssh/8.1p1, vendor/openzfs/20210210, vendor/subversion/subversion-1.14.1, vendor/NetBSD/bmake/20210206, vendor/unbound/1.13.1, vendor/bc/3.2.6, vendor/atf/20210128, vendor/sqlite3/sqlite-3340100, vendor/tzdata/tzdata2021a, vendor/device-tree/5.10, vendor/device-tree/5.9, vendor/NetBSD/bmake/20210110 |
|
#
0659df6f |
| 12-Jan-2021 |
Konstantin Belousov <kib@FreeBSD.org> |
vm_map_protect: allow to set prot and max_prot in one go.
This prevents a situation where other thread modifies map entries permissions between setting max_prot, then relocking, then setting prot, c
vm_map_protect: allow to set prot and max_prot in one go.
This prevents a situation where other thread modifies map entries permissions between setting max_prot, then relocking, then setting prot, confusing the operation outcome. E.g. you can get an error that is not possible if operation is performed atomic.
Also enable setting rwx for max_prot even if map does not allow to set effective rwx protection.
Reviewed by: brooks, markj (previous version) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D28117
show more ...
|
#
2e1c94aa |
| 08-Jan-2021 |
Konstantin Belousov <kib@FreeBSD.org> |
Implement enforcing write XOR execute mapping policy.
It is checked in vm_map_insert() and vm_map_protect() that PROT_WRITE | PROT_EXEC are never specified together, if vm_map has MAP_WX flag set. F
Implement enforcing write XOR execute mapping policy.
It is checked in vm_map_insert() and vm_map_protect() that PROT_WRITE | PROT_EXEC are never specified together, if vm_map has MAP_WX flag set. FreeBSD control flag allows specific binary to request WX exempt, and there are per ABI boolean sysctls kern.elf{32,64}.allow_wx to enable/ disable globally.
Reviewed by: emaste, jhb Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D28050
show more ...
|
Revision tags: vendor/openzfs/20210107, vendor/acpica/20210105, vendor/acpica/20201217, vendor/llvm-project/llvmorg-11.0.1-0-g43ff75f2c3fe, vendor/llvm-project/llvmorg-11.0.1-rc2-0-g43ff75f2c3f, vendor/pnglite/20130820, vendor/terminus/terminus-font-4.48, vendor/tzdata/tzdata2020f, vendor/libarchive/3.5.1, vendor/bc/3.2.4, vendor/lua/5.4.2, vendor/zstd/1.4.8, vendor/tzdata/tzdata2020e, vendor/unbound/1.13.0, vendor/openssl/1.1.1i, vendor/bc/3.2.3, vendor/libarchive/3.5.0 |
|
#
cd853791 |
| 28-Nov-2020 |
Konstantin Belousov <kib@FreeBSD.org> |
Make MAXPHYS tunable. Bump MAXPHYS to 1M.
Replace MAXPHYS by runtime variable maxphys. It is initialized from MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys.
Make b_pag
Make MAXPHYS tunable. Bump MAXPHYS to 1M.
Replace MAXPHYS by runtime variable maxphys. It is initialized from MAXPHYS by default, but can be also adjusted with the tunable kern.maxphys.
Make b_pages[] array in struct buf flexible. Size b_pages[] for buffer cache buffers exactly to atop(maxbcachebuf) (currently it is sized to atop(MAXPHYS)), and b_pages[] for pbufs is sized to atop(maxphys) + 1. The +1 for pbufs allow several pbuf consumers, among them vmapbuf(), to use unaligned buffers still sized to maxphys, esp. when such buffers come from userspace (*). Overall, we save significant amount of otherwise wasted memory in b_pages[] for buffer cache buffers, while bumping MAXPHYS to desired high value.
Eliminate all direct uses of the MAXPHYS constant in kernel and driver sources, except a place which initialize maxphys. Some random (and arguably weird) uses of MAXPHYS, e.g. in linuxolator, are converted straight. Some drivers, which use MAXPHYS to size embeded structures, get private MAXPHYS-like constant; their convertion is out of scope for this work.
Changes to cam/, dev/ahci, dev/ata, dev/mpr, dev/mpt, dev/mvs, dev/siis, where either submitted by, or based on changes by mav.
Suggested by: mav (*) Reviewed by: imp, mav, imp, mckusick, scottl (intermediate versions) Tested by: pho Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D27225
show more ...
|
Revision tags: vendor/bc/3.2.0, vendor/NetBSD/bmake/20201117, vendor/ena-com/2.3.0, vendor/ena-com/2.2.1, vendor/acpica/20201113 |
|
#
20f02659 |
| 11-Nov-2020 |
Mark Johnston <markj@FreeBSD.org> |
vm_map: Handle kernel map entry allocator recursion
On platforms without a direct map[*], vm_map_insert() may in rare situations need to allocate a kernel map entry in order to allocate kernel map e
vm_map: Handle kernel map entry allocator recursion
On platforms without a direct map[*], vm_map_insert() may in rare situations need to allocate a kernel map entry in order to allocate kernel map entries. This poses a problem similar to the one solved for vmem boundary tags by vmem_bt_alloc(). In fact the kernel map case is a bit more complicated since we must allocate entries with the kernel map locked, whereas vmem can recurse into itself because boundary tags are allocated up-front.
The solution is to add a custom slab allocator for kmapentzone which allocates KVA directly from kernel_map, bypassing the kmem_* layer. This avoids mutual recursion with the vmem btag allocator. Then, when vm_map_insert() allocates a new kernel map entry, it avoids triggering allocation of a new slab with M_NOVM until after the insertion is complete. Instead, vm_map_insert() allocates from the reserve and sets a flag in kernel_map to trigger re-population of the reserve just before the map is unlocked. This places an implicit upper bound on the number of kernel map entries that may be allocated before the kernel map lock is released, but in general a bound of 1 suffices.
[*] This also comes up on amd64 with UMA_MD_SMALL_ALLOC undefined, a configuration required by some kernel sanitizers.
Discussed with: kib, rlibby Reported by: andrew Tested by: pho (i386 and amd64 with !UMA_MD_SMALL_ALLOC) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D26851
show more ...
|
Revision tags: vendor/NetBSD/bmake/20201101 |
|
#
f7db0c95 |
| 04-Nov-2020 |
Mark Johnston <markj@FreeBSD.org> |
vmspace: Convert to refcount(9)
This is mostly mechanical except for vmspace_exit(). There, use the new refcount_release_if_last() to avoid switching to vmspace0 unless other processes are sharing
vmspace: Convert to refcount(9)
This is mostly mechanical except for vmspace_exit(). There, use the new refcount_release_if_last() to avoid switching to vmspace0 unless other processes are sharing the vmspace. In that case, upon switching to vmspace0 we can unconditionally release the reference.
Remove the volatile qualifier from vm_refcnt now that accesses are protected using refcount(9) KPIs.
Reviewed by: alc, kib, mmel MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D27057
show more ...
|
Revision tags: vendor/unbound/1.12.0, vendor/less/v563, release/12.2.0, upstream/12.2.0, vendor/tzdata/tzdata2020d, vendor/tzdata/tzdata2020c, vendor/openzfs/2.0.0-rc3-gfc5966, vendor/lua/5.3.6, vendor/llvm-project/llvmorg-11.0.0-0-g176249bd673, vendor/acpica/20200925, vendor/tzdata/tzdata2020b |
|
#
f31695cc |
| 02-Oct-2020 |
Mark Johnston <markj@FreeBSD.org> |
Implement sparse core dumps
Currently we allocate and map zero-filled anonymous pages when dumping core. This can result in lots of needless disk I/O and page allocations. This change tries to mak
Implement sparse core dumps
Currently we allocate and map zero-filled anonymous pages when dumping core. This can result in lots of needless disk I/O and page allocations. This change tries to make the core dumper more clever and represent unbacked ranges of virtual memory by holes in the core dump file.
Add a new page fault type, VM_FAULT_NOFILL, which causes vm_fault() to clean up and return an error when it would otherwise map a zero-filled page. Then, in the core dumper code, prefault all user pages and handle errors by simply extending the size of the core file. This also fixes a bug related to the fact that vn_io_fault1() does not attempt partial I/O in the face of errors from vm_fault_quick_hold_pages(): if a truncated file is mapped into a user process, an attempt to dump beyond the end of the file results in an error, but this means that valid pages immediately preceding the end of the file might not have been dumped either.
The change reduces the core dump size of trivial programs by a factor of ten simply by excluding unaccessed libc.so pages.
PR: 249067 Reviewed by: kib Tested by: pho MFC after: 1 month Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D26590
show more ...
|
Revision tags: vendor/openzfs/2.0-rc3-gfc5966, vendor/llvm-project/llvmorg-11.0.0-rc5-0-g60a25202a7d, vendor/bc/3.1.6, vendor/nvi/2.2.0-05ed8b9, vendor/openssl/1.1.1h, vendor/openzfs/2.0-rc2-g4ce06f, vendor/llvm-project/llvmorg-11.0.0-rc2-91-g6e042866c30, vendor/lib9p/9d5aee77bcc1bf0e79b0a3bfefff5fdf2146283c |
|
#
e2e80fb3 |
| 09-Sep-2020 |
Konstantin Belousov <kib@FreeBSD.org> |
vm_map: Add a map entry kind that can only be clipped at specific boundary.
The entries and their clip boundaries must be aligned on supported superpages sizes from pagesizes[]. vm_map operations r
vm_map: Add a map entry kind that can only be clipped at specific boundary.
The entries and their clip boundaries must be aligned on supported superpages sizes from pagesizes[]. vm_map operations return Mach error KERN_INVALID_ARGUMENT, which is usually translated to EINVAL, if it would require clip not at the boundary.
In other words, entries force preserving virtual addresses superpage properties.
Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D24652
show more ...
|
#
7a9f2da3 |
| 09-Sep-2020 |
Konstantin Belousov <kib@FreeBSD.org> |
Add vm_map_find_aligned(9).
Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D24652
|
Revision tags: vendor/nvi/2.2.0, vendor/NetBSD/bmake/20200902, vendor/openzfs/2.0-rc1-gfd20a8, vendor/openzfs/2.0-rc1-ga00c61, vendor/openzfs/2.0-rc0-g184df27, vendor/llvm-project/llvmorg-11.0.0-rc2-0-g414f32a9e86, vendor/unbound/1.11.0, vendor/sqlite3/sqlite-3330000 |
|
#
7dd979df |
| 17-Aug-2020 |
Mark Johnston <markj@FreeBSD.org> |
Remove the VM map zone.
Today, the zone is only used to allocate a trio of kernel maps: the kernel map itself, and the exec and pipe submaps. Maps for user processes are dynamically allocated but a
Remove the VM map zone.
Today, the zone is only used to allocate a trio of kernel maps: the kernel map itself, and the exec and pipe submaps. Maps for user processes are dynamically allocated but are embedded in the vmspace structure, which is allocated from its own zone. Make the aforementioned kernel maps statically allocated and get rid of the zone.
While here, remove a stale comment above vmspace_alloc() and change the names of locks initialized in vm_map_init() to match vmspace_zinit().
Reported by: alc Reviewed by: alc, kib MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D26052
show more ...
|
Revision tags: vendor/llvm-project/llvmorg-11.0.0-rc1-47-gff47911ddfc, vendor/bc/3.1.5, vendor/device-tree/5.8, vendor/bc/3.1.4, vendor/llvm-project/llvmorg-11.0.0-rc1-25-g903c872b169, vendor/pcg-c/20190718-83252d9, vendor/llvm-project/llvmorg-11-init-20933-g3c1fca803bc, vendor/llvm-project/llvmorg-11-init-20887-g2e10b7a39b9, vendor/acpica/20200717, vendor/sendmail/8.16.1 |
|
#
a7752896 |
| 13-Jul-2020 |
Mark Johnston <markj@FreeBSD.org> |
Add vm_map_valid_range_KBI().
This is required for standalone module builds.
Reported by: hselasky Reviewed by: dougm, hselasky, kib MFC after: 3 days Differential Revision: https://reviews.freebsd
Add vm_map_valid_range_KBI().
This is required for standalone module builds.
Reported by: hselasky Reviewed by: dougm, hselasky, kib MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D25650
show more ...
|
Revision tags: vendor/NetBSD/bmake/20200710, vendor/bc/3.1.3, vendor/NetBSD/bmake/20200704, vendor/sqlite3/sqlite-3320300, vendor/bc/3.1.1, vendor/NetBSD/bmake/20200629, vendor/llvm-project/llvmorg-10.0.1-0-gef32c611aa2, vendor/llvm-project/llvmorg-10.0.1-rc2-0-g77d76b71d7d, vendor/bc/3.0.2, vendor/llvm-project/llvmorg-10.0.0-129-gd24d5c8e308, vendor/ntp/4.2.8p15, vendor/byacc/20200330, vendor/llvm-project/llvmorg-10.0.0-97-g6f71678ecd2 |
|
#
0f1e6ec5 |
| 19-Jun-2020 |
Mark Johnston <markj@FreeBSD.org> |
Add a helper function for validating VA ranges.
Functions which take untrusted user ranges must validate against the bounds of the map, and also check for wraparound. Instead of having the same log
Add a helper function for validating VA ranges.
Functions which take untrusted user ranges must validate against the bounds of the map, and also check for wraparound. Instead of having the same logic duplicated in a number of places, add a function to check.
Reviewed by: dougm, kib Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D25328
show more ...
|
Revision tags: vendor/flex/2.6.4, vendor/file/5.39, vendor/blocklist/20200615, vendor/opencsd/v0.14.2, vendor/sqlite3/sqlite-3320200, release/11.4.0, upstream/11.4.0, vendor/sqlite3/sqlite-3320000, vendor/NetBSD/bmake/20200606, vendor/device-tree/5.7, vendor/edk2/ca407c7246bf405da6d9b1b9d93e5e7f17b4b1f9, vendor/subversion/subversion-1.14.0, vendor/apr/apr-1.7.0, vendor/acpica/20200528, vendor/ena-com/2.2.0, vendor/zstd/1.4.5, vendor/llvm-project/llvmorg-10.0.1-rc1-0-gf79cd71e145, vendor/unbound/1.10.1, vendor/NetBSD/bmake/20200517, vendor/libarchive/3.4.3, vendor/acpica/20200430, vendor/lib9p/7ddb1164407da19b9b1afb83df83ae65a71a9a66, vendor/tzdata/tzdata2020a, vendor/openssl/1.1.1g, vendor/sqlite3/sqlite-3310100, vendor/device-tree/5.6, vendor/google/googletest/1.10.0, vendor/llvm-project/llvmorg-10.0.0-0-gd32170dbd5b, vendor/bsnmp/1.14, vendor/openssl/1.1.1f, vendor/acpica/20200326, vendor/xz/5.2.5, vendor/llvm-project/llvmorg-10.0.0-rc4-5-g52c365aa9ca, vendor/openssl/1.1.1e, vendor/kyua/0.13-a685f91, vendor/lutok/0.4-8f8eaef, vendor/llvm-project/llvmorg-10.0.0-rc3-1-gc290cb61fdc, vendor/ntp/4.2.8p14, vendor/device-tree/5.5, vendor/llvm-project/llvmorg-10.0.0-rc2-70-ge5cb70267e7, vendor/ncurses/6.2-20200215, vendor/llvm-project/llvmorg-10.0.0-rc2-0-g90c78073f73, vendor/openssh/8.0p1, vendor/acpica/20200214, vendor/libarchive/3.4.2, vendor/file/5.38, vendor/ncurses/6.1-20200118, vendor/sqlite3/sqlite-3310000, vendor/Juniper/libxo/1.4.0, vendor/llvm-project/llvmorg-10-init-17538-gd11abddb32f, vendor/llvm-project/llvmorg-10-init-17468-gc4a134a5107, vendor/llvm-project/llvmorg-10-init-17466-ge26a78e7085, vendor/acpica/20200110, vendor/openssl/1.0.2u, vendor/libarchive/3.4.1, vendor/unbound/1.9.6, vendor/llvm-project/llvmorg-9.0.1, vendor/llvm-project/llvmorg-10-init-8157-g186155b89c2, vendor/llvm-project/trunk-r375505, vendor/acpica/20191213 |
|
#
7887f00d |
| 09-Dec-2019 |
Doug Moore <dougm@FreeBSD.org> |
Revert r355505. The code that it allowed to compile has been removed.
|
#
8b75b1ad |
| 08-Dec-2019 |
Doug Moore <dougm@FreeBSD.org> |
Define a vm_map method for user-space for advancing from a map entry to its successor in cases where examining a map entry requires a helper like kvm_read_all. Use that method, with kvm_read_all, to
Define a vm_map method for user-space for advancing from a map entry to its successor in cases where examining a map entry requires a helper like kvm_read_all. Use that method, with kvm_read_all, to fix procstat_getfiles_kvm, which tries to find the successor now without using such a helper. This addresses a problem introduced by r355491.
Reviewed by: markj (previous version) Discussed with: kib Differential Revision: https://reviews.freebsd.org/D22728
show more ...
|
#
3098cd73 |
| 07-Dec-2019 |
Mark Johnston <markj@FreeBSD.org> |
Provide vm_map_entry traversal routines to userspace.
This is required for now to allow libprocstat to compile.
Discussed with: dougm
|