Revision tags: vendor/llvm-project/llvmorg-18.1.5-0-g617a15a9eac9, vendor/NetBSD/bmake/20240430, vendor/libcbor/0.11.0, vendor/llvm-project/llvmorg-18.1.4-0-ge6c3289804a6, vendor/device-tree/6.8, vendor/device-tree/6.7, vendor/llvm-project/llvmorg-18.1.3-0-gc13b7485b879, vendor/device-tree/6.5, vendor/openssh/9.7p1, vendor/unbound/1.19.3, vendor/NetBSD/bmake/20240309, vendor/sqlite3/sqlite-3450100, vendor/llvm-project/llvmorg-18.1.1-0-gdba2a75e9c7e, vendor/got/diff/2023-09-15, release/13.3.0, vendor/libucl/20240206, vendor/xz/5.6.0, vendor/llvm-project/llvmorg-18.1.0-rc3-0-g6c90f8dd5463, vendor/llvm-project/llvmorg-18.1.0-rc2-53-gc7b0a6ecd442, vendor/arm-optimized-routines/v24.01, vendor/zlib/1.3.1, vendor/expat/2.6.0, vendor/unbound/1.19.1, vendor/tzcode/tzcode2024a, vendor/llvm-project/llvmorg-18.1.0-rc2-0-gc6c86965d967, vendor/tzdata/tzdata2024a, vendor/sendmail/8.18.1, vendor/acpica/20230628, vendor/acpica/20230331, vendor/llvm-project/llvmorg-18-init-18361-g22683463740e, vendor/libcxxrt/2024-01-25-fd484be8d1e94a1fcf6bc5c67e5c07b65ada19b6, vendor/llvm-project/llvmorg-18-init-18359-g93248729cfae, vendor/sqlite3/sqlite-3450000, vendor/NetBSD/bmake/20240108, vendor/llvm-project/llvmorg-18-init-16864-g3b3ee1f53424, vendor/llvm-project/llvmorg-18-init-16595-g7c00a5be5cde, vendor/llvm-project/llvmorg-18-init-16003-gfc5f51cf5af4, vendor/bc/6.7.4, vendor/ena-com/2.7.0 |
|
#
7b68fb5a |
| 26-Dec-2023 |
Mark Johnston <markj@FreeBSD.org> |
thread: Add a return value to cpu_set_upcall()
Some implementations copy data to userspace, an operation which can in principle fail. In preparation for adding a __result_use_check annotation to co
thread: Add a return value to cpu_set_upcall()
Some implementations copy data to userspace, an operation which can in principle fail. In preparation for adding a __result_use_check annotation to copyin() and related functions, let implementations of cpu_set_upcall() return an error, and check for errors when copying data to user memory.
Reviewed by: kib, jhb MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D43100
show more ...
|
Revision tags: vendor/llvm-project/llvmorg-18-init-15692-g007ed0dccd6a, vendor/tzdata/tzdata2023d, vendor/openssh/9.6p1, vendor/llvm-project/llvmorg-18-init-15088-gd14ee76181fb, vendor/llvm-project/llvmorg-18-init-14265-ga17671084db1, vendor/llvm-project/llvmorg-17.0.6-0-g6009708b4367, 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/bc/6.7.2, 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 |
|
#
685dc743 |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
sys: Remove $FreeBSD$: one-line .c pattern
Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\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, vendor/llvm-project/llvmorg-17-init-19311-gbc849e525f80, vendor/llvm-project/llvmorg-17-init-19304-gd0b54bb50e51, 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, 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 |
|
#
f49fd63a |
| 22-Sep-2022 |
John Baldwin <jhb@FreeBSD.org> |
kmem_malloc/free: Use void * instead of vm_offset_t for kernel pointers.
Reviewed by: kib, markj Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D36549
|
Revision tags: 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 |
|
#
4a5ec55a |
| 21-Jul-2022 |
Konstantin Belousov <kib@FreeBSD.org> |
amd64: expicitly re-init td_frame in copy_thread()
Otherwise we are using whatever the value was left from the previous thread run on kernel entry from usermode. Typically it would be the desired va
amd64: expicitly re-init td_frame in copy_thread()
Otherwise we are using whatever the value was left from the previous thread run on kernel entry from usermode. Typically it would be the desired value as is, but it is not guaranteed.
Reviewed by: markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D35888
show more ...
|
Revision tags: 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, 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 |
|
#
fe2c9f83 |
| 26-Apr-2022 |
Dmitry Chagin <dchagin@FreeBSD.org> |
Remove dead code.
is_physical_memory() dead since 235a54de.
Reviewed by: markj Differential revision: https://reviews.freebsd.org/D35056 MFC after: 2 weeks
|
Revision tags: 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, vendor/wpa/2.10, vendor/expat/2.4.3, vendor/sqlite3/sqlite-3370200, vendor/wpa/gb26f5c0fe, vendor/sqlite3/sqlite-3370100, vendor/file/5.41 |
|
#
254e4e5b |
| 28-Dec-2021 |
John Baldwin <jhb@FreeBSD.org> |
Simplify swi for bus_dma.
When a DMA request using bounce pages completes, a swi is triggered to schedule pending DMA requests using the just-freed bounce pages. For a long time this bus_dma swi ha
Simplify swi for bus_dma.
When a DMA request using bounce pages completes, a swi is triggered to schedule pending DMA requests using the just-freed bounce pages. For a long time this bus_dma swi has been tied to a "virtual memory" swi (swi_vm). However, all of the swi_vm implementations are the same and consist of checking a flag (busdma_swi_pending) which is always true and if set calling busdma_swi. I suspect this dates back to the pre-SMPng days and that the intention was for swi_vm to serve as a mux. However, in the current scheme there's no need for the mux.
Instead, remove swi_vm and vm_ih. Each bus_dma implementation that uses bounce pages is responsible for creating its own swi (busdma_ih) which it now schedules directly. This swi invokes busdma_swi directly removing the need for busdma_swi_pending.
One consequence is that the swi now works on RISC-V which had previously failed to invoke busdma_swi from swi_vm.
Reviewed by: imp, kib Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D33447
show more ...
|
Revision tags: 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, 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 |
|
#
ca1e447b |
| 25-Sep-2021 |
Mark Johnston <markj@FreeBSD.org> |
amd64: Avoid copying td_frame from kernel procs
When creating a new thread, we unconditionally copy td_frame from the creating thread. For threads which never return to user mode, this is unnecessa
amd64: Avoid copying td_frame from kernel procs
When creating a new thread, we unconditionally copy td_frame from the creating thread. For threads which never return to user mode, this is unnecessary since td_frame just points to the base of the stack or a random interrupt frame.
If KASAN is configured this copying may also trigger false positives since the td_frame region may contain poisoned stack regions. It was not noticed before since thread0 used a dummy proc0_tf trapframe, and kernel procs are generally created by thread0. Since commit df8dd6025af88a99d34f549fa9591a9b8f9b75b1, though, we call cpu_thread_alloc(&thread0) when initializing FPU state, which reinitializes thread0.td_frame.
Work around the problem by not copying the frame unless the copying thread came from user mode. While here, de-duplicate the copying and remove redundant re(initialization) of td_frame.
Reported by: syzbot+2ec89312bffbf38d9aec@syzkaller.appspotmail.com Reviewed by: kib Fixes: df8dd6025af8 MFC after: 2 weeks Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D32057
show more ...
|
Revision tags: 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 |
|
#
bd9e0f5d |
| 15-Sep-2021 |
Konstantin Belousov <kib@FreeBSD.org> |
amd64: eliminate td_md.md_fpu_scratch
For signal send, copyout from the user FPU save area directly.
For sigreturn, we are in sleepable context and can do temporal allocation of the transient save
amd64: eliminate td_md.md_fpu_scratch
For signal send, copyout from the user FPU save area directly.
For sigreturn, we are in sleepable context and can do temporal allocation of the transient save area. We cannot copying from userspace directly to user save area because XSAVE state needs to be validated, also partial copyins can corrupt it.
Requested by: jhb Reviewed by: jhb, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D31954
show more ...
|
#
df8dd602 |
| 13-Sep-2021 |
Konstantin Belousov <kib@FreeBSD.org> |
amd64: stop using top of the thread' kernel stack for FPU user save area
Instead do one more allocation at the thread creation time. This frees a lot of space on the stack.
Also do not use alloca(
amd64: stop using top of the thread' kernel stack for FPU user save area
Instead do one more allocation at the thread creation time. This frees a lot of space on the stack.
Also do not use alloca() for temporal storage in signal delivery sendsig() function and signal return syscall sys_sigreturn(). This saves equal amount of space, again by the cost of one more allocation at the thread creation time.
A useful experiment now would be to reduce KSTACK_PAGES.
Reviewed by: jhb, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D31954
show more ...
|
Revision tags: 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 |
|
#
de8374df |
| 12-Aug-2021 |
Dmitry Chagin <dchagin@FreeBSD.org> |
fork: Allow ABI to specify fork return values for child.
At least Linux x86 ABI's does not use carry bit and expects that the dx register is preserved. For this add a new sv_set_fork_retval hook and
fork: Allow ABI to specify fork return values for child.
At least Linux x86 ABI's does not use carry bit and expects that the dx register is preserved. For this add a new sv_set_fork_retval hook and call it from cpu_fork().
Add a short comment about touching dx in x86_set_fork_retval(), for more details see phab comments from kib@ and imp@.
Reviewed by: kib Differential revision: https://reviews.freebsd.org/D31472 MFC after: 2 weeks
show more ...
|
Revision tags: 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 |
|
#
8cd05b88 |
| 01-Jun-2021 |
Mark Johnston <markj@FreeBSD.org> |
amd64: Clear the local TSS when creating a new thread
Otherwise it is copied from the creating thread. Then, if either thread exits, the other is left with a dangling pointer, typically resulting i
amd64: Clear the local TSS when creating a new thread
Otherwise it is copied from the creating thread. Then, if either thread exits, the other is left with a dangling pointer, typically resulting in a page fault upon the next context switch.
Reported by: syzkaller Reviewed by: kib MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D30607
show more ...
|
Revision tags: 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 |
|
#
290b0d12 |
| 09-Apr-2021 |
Konstantin Belousov <kib@FreeBSD.org> |
x86: use x86_clear_dbregs() on fork
instead of manual zeroing of the debug registers file in pcb. This centralizes the cleaning code, but the practical difference is that PCB_DBREGS flag is cleared,
x86: use x86_clear_dbregs() on fork
instead of manual zeroing of the debug registers file in pcb. This centralizes the cleaning code, but the practical difference is that PCB_DBREGS flag is cleared, saving some operations on context switching.
Reviewed by: jhb Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D29687
show more ...
|
Revision tags: release/13.0.0, upstream/13.0.0, vendor/bc/4.0.0, vendor/acpica/20210331 |
|
#
8223717c |
| 30-Mar-2021 |
Konstantin Belousov <kib@FreeBSD.org> |
x86: clear %db registers in new process
Reported by: Michał Górny <mgorny@gentoo.org> PR: 254661 Reviewed by: emaste, jhb MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential revisio
x86: clear %db registers in new process
Reported by: Michał Górny <mgorny@gentoo.org> PR: 254661 Reviewed by: emaste, jhb MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D29496
show more ...
|
Revision tags: 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 |
|
#
3b57ddb0 |
| 18-Mar-2021 |
John Baldwin <jhb@FreeBSD.org> |
Rename linux_set_upcall_kse() to linux_set_upcall().
This matches the rename of cpu_set_upcall_kse() in 5c2cf818454375536fda522ba83cf67c50929e6b.
Reviewed by: kib, emaste MFC after: 1 week Sponsore
Rename linux_set_upcall_kse() to linux_set_upcall().
This matches the rename of cpu_set_upcall_kse() in 5c2cf818454375536fda522ba83cf67c50929e6b.
Reviewed by: kib, emaste MFC after: 1 week Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D29295
show more ...
|
#
a7883464 |
| 18-Mar-2021 |
John Baldwin <jhb@FreeBSD.org> |
x86: Reduce code duplication in cpu_fork() and cpu_copy_thread().
Add copy_thread() to hold shared code.
Reviewed by: kib MFC after: 1 week Sponsored by: Netflix Differential Revision: https://revi
x86: Reduce code duplication in cpu_fork() and cpu_copy_thread().
Add copy_thread() to hold shared code.
Reviewed by: kib MFC after: 1 week Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D29228
show more ...
|
Revision tags: vendor/tcsh/6.22.03-ceccc7f |
|
#
40d593d1 |
| 12-Mar-2021 |
John Baldwin <jhb@FreeBSD.org> |
x86: Update some stale comments in cpu_fork() and cpu_copy_thread().
Neither of these routines allocate stacks.
Reviewed by: kib MFC after: 1 week Sponsored by: Netflix Differential Revision: https
x86: Update some stale comments in cpu_fork() and cpu_copy_thread().
Neither of these routines allocate stacks.
Reviewed by: kib MFC after: 1 week Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D29227
show more ...
|
#
c7b02135 |
| 12-Mar-2021 |
John Baldwin <jhb@FreeBSD.org> |
x86: Always use clean FPU and segment base state for new kthreads.
Reviewed by: kib MFC after: 1 week Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D29208
|
#
755efb8d |
| 12-Mar-2021 |
John Baldwin <jhb@FreeBSD.org> |
x86: Copy the FPU/XSAVE state from the creating thread to new threads.
POSIX states that new threads created via pthread_create() should inherit the "floating point environment" from the creating th
x86: Copy the FPU/XSAVE state from the creating thread to new threads.
POSIX states that new threads created via pthread_create() should inherit the "floating point environment" from the creating thread.
Discussed with: kib MFC after: 1 week Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D29204
show more ...
|
#
92211458 |
| 12-Mar-2021 |
John Baldwin <jhb@FreeBSD.org> |
amd64: Only update fsbase/gsbase in pcb for curthread.
Before the pcb is copied to the new thread during cpu_fork() and cpu_copy_thread(), the kernel re-reads the current register values in case the
amd64: Only update fsbase/gsbase in pcb for curthread.
Before the pcb is copied to the new thread during cpu_fork() and cpu_copy_thread(), the kernel re-reads the current register values in case they are stale. This is done by setting PCB_FULL_IRET in pcb_flags.
This works fine for user threads, but the creation of kernel processes and kernel threads do not follow the normal synchronization rules for pcb_flags. Specifically, new kernel processes are always forked from thread0, not from curthread, so adjusting pcb_flags via a simple instruction without the LOCK prefix can race with thread0 running on another CPU. Similarly, kthread_add() clones from the first thread in the relevant kernel process, not from curthread. In practice, Netflix encountered a panic where the pcb_flags in the first kthread of the KTLS process were trashed due to update_pcb_bases() in cpu_copy_thread() running from thread0 to create one of the other KTLS threads racing with the first KTLS kthread calling fpu_kern_thread() on another CPU. In the panicking case, the write to update pcb_flags in fpu_kern_thread() was lost triggering an "Unregistered use of FPU in kernel" panic when the first KTLS kthread later tried to use the FPU.
Reported by: gallatin Discussed with: kib MFC after: 1 week Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D29023
show more ...
|
Revision tags: 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, 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, vendor/bc/3.2.0, vendor/NetBSD/bmake/20201117, vendor/ena-com/2.3.0, vendor/ena-com/2.2.1, vendor/acpica/20201113, vendor/NetBSD/bmake/20201101, 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, 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 |
|
#
c26391f4 |
| 15-Sep-2020 |
Edward Tomasz Napierala <trasz@FreeBSD.org> |
Move SV_ABI_ERRNO translation into linux-specific code, to simplify the syscall path and declutter it a bit. No functional changes intended.
Reviewed by: kib (earlier version) MFC after: 2 weeks Sp
Move SV_ABI_ERRNO translation into linux-specific code, to simplify the syscall path and declutter it a bit. No functional changes intended.
Reviewed by: kib (earlier version) MFC after: 2 weeks Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D26378
show more ...
|
Revision tags: vendor/lib9p/9d5aee77bcc1bf0e79b0a3bfefff5fdf2146283c, 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 |
|
#
25f2da2e |
| 23-Aug-2020 |
Konstantin Belousov <kib@FreeBSD.org> |
Add amd64 procctl(2) ops to manage forced LA48/LA57 VA after exec.
Tested by: pho (LA48 hardware) Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D25273
|
Revision tags: vendor/unbound/1.11.0, vendor/sqlite3/sqlite-3330000, 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, 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, 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 |
|
#
59838c1a |
| 01-Apr-2020 |
John Baldwin <jhb@FreeBSD.org> |
Retire procfs-based process debugging.
Modern debuggers and process tracers use ptrace() rather than procfs for debugging. ptrace() has a supserset of functionality available via procfs and new deb
Retire procfs-based process debugging.
Modern debuggers and process tracers use ptrace() rather than procfs for debugging. ptrace() has a supserset of functionality available via procfs and new debugging features are only added to ptrace(). While the two debugging services share some fields in struct proc, they each use dedicated fields and separate code. This results in extra complexity to support a feature that hasn't been enabled in the default install for several years.
PR: 244939 (exp-run) Reviewed by: kib, mjg (earlier version) Relnotes: yes Differential Revision: https://reviews.freebsd.org/D23837
show more ...
|
Revision tags: 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, vendor/device-tree/5.4, vendor/openresolv/3.9.2, vendor/file/5.37, vendor/Juniper/libxo/1.3.1, vendor/Juniper/libxo/1.3.0, vendor/NetBSD/blacklist/20191106, vendor/zstd/1.4.4, vendor/sqlite3/sqlite-3300100, release/12.1.0, upstream/12.1.0 |
|
#
5e921ff4 |
| 25-Oct-2019 |
Konstantin Belousov <kib@FreeBSD.org> |
amd64: move pcb out of kstack to struct thread.
This saves 320 bytes of the precious stack space.
The only negative aspect of the change I can think of is that the struct thread increased by 320 by
amd64: move pcb out of kstack to struct thread.
This saves 320 bytes of the precious stack space.
The only negative aspect of the change I can think of is that the struct thread increased by 320 bytes obviously, and that 320 bytes are not swapped out anymore. I believe the freed stack space is much more important than that. Also, current struct thread size is 1392 bytes on amd64, so UMA will allocate two thread structures per (4KB) slab, which leaves a space for pcb without increasing zone memory use.
Reviewed by: alc, markj Tested by: pho Sponsored by: The FreeBSD Foundation MFC after: 2 weeks Differential revision: https://reviews.freebsd.org/D22138
show more ...
|
Revision tags: vendor/llvm-openmp/openmp-trunk-r375505, vendor/lldb/lldb-trunk-r375505, vendor/lld/lld-trunk-r375505, vendor/llvm-libunwind/libunwind-trunk-r375505, vendor/libc++/libc++-trunk-r375505, vendor/compiler-rt/compiler-rt-trunk-r375505, vendor/clang/clang-trunk-r375505, vendor/llvm/llvm-trunk-r375505, vendor/tcsh/6.21.00-83c5be0, vendor/acpica/20191018, vendor/opencsd/a1961c91b02a92f3c6ed8b145c636ac4c5565aca, vendor/processor-trace/892e12c5a27bda5806d1e63269986bb4171b5a8b, vendor/tcsh/6.21.00, vendor/tcpdump/4.9.3, vendor/libpcap/1.9.1, vendor/device-tree/5.3, vendor/device-tree/5.2, vendor/lldb/lldb-release_900-r372316, vendor/clang/clang-release_900-r372316, vendor/llvm/llvm-release_900-r372316, vendor/tzdata/tzdata2019c, vendor/openssl/1.0.2t, vendor/openssl/1.1.1d, vendor/NetBSD/libedit/2019-09-10, vendor/lld/lld-release_90-r371301, vendor/lld/lld-release_900-r372316, vendor/clang/clang-release_90-r371301, vendor/llvm/llvm-release_90-r371301, vendor/lld/lld-release_90-r370514, vendor/libc++/libc++-release_90-r370514, vendor/libc++/libc++-release_90-r371301, vendor/libc++/libc++-release_900-r372316, vendor/compiler-rt/compiler-rt-release_90-r370514, vendor/compiler-rt/compiler-rt-release_90-r371301, vendor/compiler-rt/compiler-rt-release_900-r372316, vendor/clang/clang-release_90-r370514, vendor/llvm/llvm-release_90-r370514 |
|
#
a2a0f906 |
| 29-Aug-2019 |
Konstantin Belousov <kib@FreeBSD.org> |
Centralize __pcpu definitions.
Many extern struct pcpu <something>__pcpu declarations were copied/pasted in sources. The issue is that the definition is MD, but it cannot be provided by machine/pcp
Centralize __pcpu definitions.
Many extern struct pcpu <something>__pcpu declarations were copied/pasted in sources. The issue is that the definition is MD, but it cannot be provided by machine/pcpu.h due to actual struct pcpu defined in sys/pcpu.h later than the inclusion of machine/pcpu.h. This forced the copying when other code needed direct access to __pcpu. There is no way around it, due to machine/pcpu.h supplying part of struct pcpu fields.
To work around the problem, add a new machine/pcpu_aux.h header, which should fill any needed MD definitions after struct pcpu definition is completed. This allows to remove copies of __pcpu spread around the source. Also on x86 it makes it possible to remove work arounds like OFFSETOF_CURTHREAD or clang specific warnings supressions.
Reported and tested by: lwhsu, bcran Reviewed by: imp, markj (previous version) Discussed with: jhb Sponsored by: The FreeBSD Foundation Differential revision: https://reviews.freebsd.org/D21418
show more ...
|