#
34ebdcea |
| 07-Dec-2018 |
Mateusz Guzik <mjg@FreeBSD.org> |
Manage process-related IDs with bitmaps
Currently unique pid allocation on fork often requires a full walk of process, group, session lists to make sure it is not used by anything. This has a side e
Manage process-related IDs with bitmaps
Currently unique pid allocation on fork often requires a full walk of process, group, session lists to make sure it is not used by anything. This has a side effect of requiring proctree to be held along with allproc, which adds more contention in poudriere -j 128.
The patch below implements trivial bitmaps which gets rid of the problem. Dedicated lock is introduced to manage IDs.
While here a bug was discovered: all processes would inherit reap id from the first process spawned by init. This had a side effect of keeping the ID used and when allocation rolls over to the beginning it keeps being skipped.
The patch is loosely based on initial work by mjoras@.
Reviewed by: kib Sponsored by: The FreeBSD Foundation
show more ...
|
Revision tags: release/12.0.0 |
|
#
1e9a1bf5 |
| 29-Nov-2018 |
Mateusz Guzik <mjg@FreeBSD.org> |
proc: create a dedicated lock for zombproc to ligthen the load on allproc_lock
waitpid always takes proctree to evaluate the list, but only takes allproc if it can reap. With this patch allproc is n
proc: create a dedicated lock for zombproc to ligthen the load on allproc_lock
waitpid always takes proctree to evaluate the list, but only takes allproc if it can reap. With this patch allproc is no longer taken, which helps during poudriere -j 128.
Discussed with: kib Sponsored by: The FreeBSD Foundation
show more ...
|
#
3d5db455 |
| 24-Nov-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r340427 through r340868.
|
#
e3d3e828 |
| 23-Nov-2018 |
Mateusz Guzik <mjg@FreeBSD.org> |
Revert "fork: fix use-after-free with vfork"
This unreliably breaks libc handling of vfork where forking succeded, but execve did not.
vfork code in libc performs waitpid with WNOHANG in case of fa
Revert "fork: fix use-after-free with vfork"
This unreliably breaks libc handling of vfork where forking succeded, but execve did not.
vfork code in libc performs waitpid with WNOHANG in case of failed exec. With the fix exit codepath was waking up the parent before the child fully transitioned to a zombie. Woken up parent would waitpid, which could find a not-yet-zombie child and fail to reap it due to the WNOHANG flag.
While removing the flag fixes the problem, it is not an option due to older releases which would still suffer from the kernel change.
Revert the fix until a solution can be worked out.
Note that while use-after-free which gets back due to the revert is a real bug, it's side-effects are limited due to the fact that struct proc memory is never released by UMA.
show more ...
|
#
a5ac8272 |
| 22-Nov-2018 |
Mateusz Guzik <mjg@FreeBSD.org> |
fork: remove avoidable proc lock/unlock pair
We don't have to access the process after making it runnable, so there is no need to hold it either.
Sponsored by: The FreeBSD Foundation
|
#
b00b27e9 |
| 22-Nov-2018 |
Mateusz Guzik <mjg@FreeBSD.org> |
fork: fix use-after-free with vfork
The pointer to the child is stored without any reference held. Then it is blindly used to wait until P_PPWAIT is cleared. However, if the child is autoreaped it c
fork: fix use-after-free with vfork
The pointer to the child is stored without any reference held. Then it is blindly used to wait until P_PPWAIT is cleared. However, if the child is autoreaped it could have exited and get freed before the parent started waiting.
Use the existing hold mechanism to mitigate the problem. Most common case of doing exec remains unchanged. The corner case of doing exit performs wake up before waiting for holds to clear.
Reviewed by: kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D18295
show more ...
|
#
3d3e6793 |
| 21-Nov-2018 |
Mateusz Guzik <mjg@FreeBSD.org> |
proc: implement pid hash locks and an iterator
forks, exits and waits are frequently stalled during poudriere -j 128 runs due to killpg and process list exports performed for each package.
Both use
proc: implement pid hash locks and an iterator
forks, exits and waits are frequently stalled during poudriere -j 128 runs due to killpg and process list exports performed for each package.
Both uses take the allproc lock. The latter case can be modified to iterate over the hash with finer grained locking instead.
Reviewed by: kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17817
show more ...
|
#
2c054ce9 |
| 16-Nov-2018 |
Mateusz Guzik <mjg@FreeBSD.org> |
proc: always store parent pid in p_oppid
Doing so removes the dependency on proctree lock from sysctl process list export which further reduces contention during poudriere -j 128 runs.
Reviewed by:
proc: always store parent pid in p_oppid
Doing so removes the dependency on proctree lock from sysctl process list export which further reduces contention during poudriere -j 128 runs.
Reviewed by: kib (previous version) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17825
show more ...
|
Revision tags: release/11.2.0 |
|
#
6e22bbf6 |
| 21-Jun-2018 |
Konstantin Belousov <kib@FreeBSD.org> |
fork: avoid endless wait with PTRACE_FORK and RFSTOPPED.
An RFSTOPPED thread can't clean TDB_STOPATFORK, which is done in the fork_return() in its context, so parent is stuck forever. Triggered whe
fork: avoid endless wait with PTRACE_FORK and RFSTOPPED.
An RFSTOPPED thread can't clean TDB_STOPATFORK, which is done in the fork_return() in its context, so parent is stuck forever. Triggered when trying to ptrace linux process. Instead of waiting for the new thread to clear TDB_STOPATFORK, tag it as traced and reparent to the debugger in do_fork(), and let it only notify the debugger when run.
Submitted by: Yanko Yankulov <yanko.yankulov@gmail.com> Reviewed by: jhb MFC after: 1 week X-MFC-Note: keep p_dbgwait placeholder intact Differential revision: https://reviews.freebsd.org/D15857
show more ...
|
#
81d68271 |
| 20-Feb-2018 |
Mateusz Guzik <mjg@FreeBSD.org> |
Reduce contention on the proctree lock during heavy package build.
There is a proctree -> allproc ordering established.
Most of the time it is either xlock -> xlock or slock -> slock.
On fork howe
Reduce contention on the proctree lock during heavy package build.
There is a proctree -> allproc ordering established.
Most of the time it is either xlock -> xlock or slock -> slock.
On fork however there is a slock -> xlock pair which results in pathological wait times due to threads keeping proctree held for reading and all waiting on allproc. Switch this to xlock -> xlock. Longer term fix would get rid of proctree in this place to begin with. Right now it is necessary to walk the session/process group lists to determine which id is free. The walk can be avoided e.g. with bitmaps.
The exit path used to have one place which dealt with allproc and then with proctree. Move the allproc acquire into the section protected by proctree. This reduces contention against threads waiting on proctree in the fork codepath - the fork proctree holder does not have to wait for allproc as often.
Finally, move tidhash manipulation outside of the area protected by either of these locks. The removal from the hash was already unprotected. There is no legitimate reason to look up thread ids for a process still under construction.
This results in about 50% wait time reduction during -j 128 package build.
show more ...
|
#
65f29b9c |
| 17-Feb-2018 |
Mateusz Guzik <mjg@FreeBSD.org> |
Postpone sx_sunlock(&proctree_lock) on fork until after allproc is dropped.
There is a significant contention on the lock during -j 128 package build. This change drops total wait time on this lock
Postpone sx_sunlock(&proctree_lock) on fork until after allproc is dropped.
There is a significant contention on the lock during -j 128 package build. This change drops total wait time on this lock by 60%.
show more ...
|
#
8e23158a |
| 14-Jan-2018 |
Bjoern A. Zeeb <bz@FreeBSD.org> |
Remove trailing whitespace. No functional change.
|
#
72bfb31a |
| 13-Jan-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r327886 through r327930.
|
#
3f289c3f |
| 12-Jan-2018 |
Jeff Roberson <jeff@FreeBSD.org> |
Implement 'domainset', a cpuset based NUMA policy mechanism. This allows userspace to control NUMA policy administratively and programmatically.
Implement domainset based iterators in the page laye
Implement 'domainset', a cpuset based NUMA policy mechanism. This allows userspace to control NUMA policy administratively and programmatically.
Implement domainset based iterators in the page layer.
Remove the now legacy numa_* syscalls.
Cleanup some header polution created by having seq.h in proc.h.
Reviewed by: markj, kib Discussed with: alc Tested by: pho Sponsored by: Netflix, Dell/EMC Isilon Differential Revision: https://reviews.freebsd.org/D13403
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.
|
#
2ca45184 |
| 09-Nov-2017 |
Matt Joras <mjoras@FreeBSD.org> |
Introduce EVENTHANDLER_LIST and some users.
This introduces a facility to EVENTHANDLER(9) for explicitly defining a reference to an event handler list. This is useful since previously all invokers o
Introduce EVENTHANDLER_LIST and some users.
This introduces a facility to EVENTHANDLER(9) for explicitly defining a reference to an event handler list. This is useful since previously all invokers of events had to do a locked traversal of the global list of event handler lists in order to find the appropriate event handler list. By keeping a pointer to the appropriate list an invoker can avoid this traversal completely. The pointer is initialized with SYSINIT(9) during the eventhandler stage. Users registering interest in events do not need to know if the event is backed by such a list, since the list is added to the global list of lists. As with lists that are not pre-defined it is safe to register for the events before the list has been created.
This converts the process_* and thread_* events to using the new facility, as these are events whose locked traversals end up showing up significantly in ports build workflows (and presumably other workflows with many short lived threads/procs). It may be advantageous to convert other events to using the new facility.
The el_flags field is now unused, but leave it be so that this revision can be MFC'd.
Reviewed by: bdrewery, markj, mjg Approved by: rstone (mentor) In collaboration with: ian MFC after: 4 weeks Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12814
show more ...
|
Revision tags: release/10.4.0 |
|
#
8fcbcc2d |
| 16-Sep-2017 |
Enji Cooper <ngie@FreeBSD.org> |
MFhead@r323635
|
#
b754c279 |
| 13-Sep-2017 |
Navdeep Parhar <np@FreeBSD.org> |
MFH @ r323558.
|
#
008a0935 |
| 10-Sep-2017 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
If the user tries to set kern.randompid to 1 (which is meaningless), set it to a random value between 100 and 1123, rather than 0 as before.
Submitted by: Marie Helene Kvello-Aune <marieheleneka@gma
If the user tries to set kern.randompid to 1 (which is meaningless), set it to a random value between 100 and 1123, rather than 0 as before.
Submitted by: Marie Helene Kvello-Aune <marieheleneka@gmail.com> MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D5336
show more ...
|
Revision tags: release/11.1.0 |
|
#
4198293b |
| 17-Jun-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r319801 through r320041.
|
#
2d88da2f |
| 12-Jun-2017 |
Konstantin Belousov <kib@FreeBSD.org> |
Move struct syscall_args syscall arguments parameters container into struct thread.
For all architectures, the syscall trap handlers have to allocate the structure on the stack. The structure takes
Move struct syscall_args syscall arguments parameters container into struct thread.
For all architectures, the syscall trap handlers have to allocate the structure on the stack. The structure takes 88 bytes on 64bit arches which is not negligible. Also, it cannot be easily found by other code, which e.g. caused duplication of some members of the structure to struct thread already. The change removes td_dbg_sc_code and td_dbg_sc_nargs which were directly copied from syscall_args.
The structure is put into the copied on fork part of the struct thread to make the syscall arguments information correct in the child after fork.
This move will also allow several more uses shortly.
Reviewed by: jhb (previous version) Sponsored by: The FreeBSD Foundation MFC after: 3 weeks X-Differential revision: https://reviews.freebsd.org/D11080
show more ...
|
#
554491ff |
| 20-Apr-2017 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r316992 through r317215.
|
#
83c9dea1 |
| 17-Apr-2017 |
Gleb Smirnoff <glebius@FreeBSD.org> |
- Remove 'struct vmmeter' from 'struct pcpu', leaving only global vmmeter in place. To do per-cpu stats, convert all fields that previously were maintained in the vmmeters that sit in pcpus to c
- Remove 'struct vmmeter' from 'struct pcpu', leaving only global vmmeter in place. To do per-cpu stats, convert all fields that previously were maintained in the vmmeters that sit in pcpus to counter(9). - Since some vmmeter stats may be touched at very early stages of boot, before we have set up UMA and we can do counter_u64_alloc(), provide an early counter mechanism: o Leave one spare uint64_t in struct pcpu, named pc_early_dummy_counter. o Point counter(9) fields of vmmeter to pcpu[0].pc_early_dummy_counter, so that at early stages of boot, before counters are allocated we already point to a counter that can be safely written to. o For sparc64 that required a whole dummy pcpu[MAXCPU] array.
Further related changes: - Don't include vmmeter.h into pcpu.h. - vm.stats.vm.v_swappgsout and vm.stats.vm.v_swappgsin changed to 64-bit, to match kernel representation. - struct vmmeter hidden under _KERNEL, and only vmstat(1) is an exclusion.
This is based on benno@'s 4-year old patch: https://lists.freebsd.org/pipermail/freebsd-arch/2013-July/014471.html
Reviewed by: kib, gallatin, marius, lidl Differential Revision: https://reviews.freebsd.org/D10156
show more ...
|