#
ad3b9257 |
| 15-Aug-2004 |
John-Mark Gurney <jmg@FreeBSD.org> |
Add locking to the kqueue subsystem. This also makes the kqueue subsystem a more complete subsystem, and removes the knowlege of how things are implemented from the drivers. Include locking around
Add locking to the kqueue subsystem. This also makes the kqueue subsystem a more complete subsystem, and removes the knowlege of how things are implemented from the drivers. Include locking around filter ops, so a module like aio will know when not to be unloaded if there are outstanding knotes using it's filter ops.
Currently, it uses the MTX_DUPOK even though it is not always safe to aquire duplicate locks. Witness currently doesn't support the ability to discover if a dup lock is ok (in some cases).
Reviewed by: green, rwatson (both earlier versions)
show more ...
|
#
732d9528 |
| 09-Aug-2004 |
Julian Elischer <julian@FreeBSD.org> |
Increase the amount of data exported by KTR in the KTR_RUNQ setting. This extra data is needed to really follow what is going on in the threaded case.
|
#
0047b9a9 |
| 27-Jul-2004 |
Bosko Milekic <bmilekic@FreeBSD.org> |
Move the schedlock owner state update following the context switch in fork_exit() to before anything else is done (but keep schedlock for the deadthread check). This means one less nasty bug if ever
Move the schedlock owner state update following the context switch in fork_exit() to before anything else is done (but keep schedlock for the deadthread check). This means one less nasty bug if ever in the future whatever might have been called before the update played with schedlock or critical sections.
Discussed with: tjr
show more ...
|
#
66d5c640 |
| 26-Jul-2004 |
Colin Percival <cperciva@FreeBSD.org> |
In revision 1.228, I accidentally broke the "total number of processes in the system" resource limit code: When checking if the caller has superuser privileges, we should be checking the *real* user,
In revision 1.228, I accidentally broke the "total number of processes in the system" resource limit code: When checking if the caller has superuser privileges, we should be checking the *real* user, not the *effective* user. (In general, resource limiting is done based on the real user, in order to avoid resource-exhaustion-by-setuid-program attacks.)
Now that a SUSER_RUID flag to suser_cred exists, use it here to return this code to its correct behaviour.
Pointed out by: rwatson
show more ...
|
#
55d44f79 |
| 19-Jul-2004 |
Julian Elischer <julian@FreeBSD.org> |
When calling scheduler entrypoints for creating new threads and processes, specify "us" as the thread not the process/ksegrp/kse. You can always find the others from the thread but the converse is no
When calling scheduler entrypoints for creating new threads and processes, specify "us" as the thread not the process/ksegrp/kse. You can always find the others from the thread but the converse is not true. Theorotically this would lead to runtime being allocated to the wrong entity in some cases though it is not clear how often this actually happenned. (would only affect threaded processes and would probably be pretty benign, but it WAS a bug..)
Reviewed by: peter
show more ...
|
#
49bddf0c |
| 13-Jul-2004 |
Poul-Henning Kamp <phk@FreeBSD.org> |
fix compilation.
|
#
65bba83f |
| 13-Jul-2004 |
Colin Percival <cperciva@FreeBSD.org> |
Replace "uid != 0" with "suser(td->td_ucred) != 0" when checking if we've hit the maximum number of processes. The last ten processes are reserved for the *non-jailed* superuser.
|
#
247aba24 |
| 26-Jun-2004 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Allocate TIDs in thread_init() and deallocate them in thread_fini(). The overhead of unconditionally allocating TIDs (and likewise, unconditionally deallocating them), is amortized across multiple th
Allocate TIDs in thread_init() and deallocate them in thread_fini(). The overhead of unconditionally allocating TIDs (and likewise, unconditionally deallocating them), is amortized across multiple thread creations by the way UMA makes it possible to have type-stable storage. Previously the cost was kept down by having threads created as part of a fork operation use the process' PID as the TID. While this had some nice properties, it also introduced complexity in the way TIDs were allocated. Most importantly, by using the type-stable storage that UMA gives us this was also unnecessary.
This change affects how core dumps are created and in particular how the PRSTATUS notes are dumped. Since we don't have a thread with a TID equalling the PID, we now need a different way to preserve the old and previous behavior. We do this by having the given thread (i.e. the thread passed to the core dump code in td) dump it's state first and fill in pr_pid with the actual PID. All other threads will have pr_pid contain their TIDs. The upshot of all this is that the debugger will now likely select the right LWP (=TID) as the initial thread.
Credits to: julian@ for spotting how we can utilize UMA. Thanks to: all who provided julian@ with test results.
show more ...
|
Revision tags: release/4.10.0_cvs, release/4.10.0 |
|
#
7f8a436f |
| 05-Apr-2004 |
Warner Losh <imp@FreeBSD.org> |
Remove advertising clause from University of California Regent's license, per letter dated July 22, 1999.
Approved by: core
|
#
fdcac928 |
| 03-Apr-2004 |
Marcel Moolenaar <marcel@FreeBSD.org> |
Assign thread IDs to kernel threads. The purpose of the thread ID (tid) is twofold: 1. When a 1:1 or M:N threaded process dumps core, we need to put the register state of each of its kernel thread
Assign thread IDs to kernel threads. The purpose of the thread ID (tid) is twofold: 1. When a 1:1 or M:N threaded process dumps core, we need to put the register state of each of its kernel threads in the core file. This can only be done by differentiating the pid field in the respective note. For this we need the tid. 2. When thread support is present for remote debugging the kernel with gdb(1), threads need to be identified by an integer due to limitations in the remote protocol. This requires having a tid.
To minimize the impact of having thread IDs, threads that are created as part of a fork (i.e. the initial thread in a process) will inherit the process ID (i.e. tid=pid). Subsequent threads will have IDs larger than PID_MAX to avoid interference with the pid allocation algorithm. The assignment of tids is handled by thread_new_tid().
The thread ID allocation algorithm has been written with 3 assumptions in mind: 1. IDs need to be created as fast a possible, 2. Reuse of IDs may happen instantaneously, 3. Someone else will write a better algorithm.
show more ...
|
#
a5bdcb2a |
| 14-Mar-2004 |
Peter Wemm <peter@FreeBSD.org> |
Make the process_exit eventhandler run without Giant. Add Giant hooks in the two consumers that need it.. processes using AIO and netncp. Update docs. Say that process_exec is called with Giant, bu
Make the process_exit eventhandler run without Giant. Add Giant hooks in the two consumers that need it.. processes using AIO and netncp. Update docs. Say that process_exec is called with Giant, but not to depend on it. All our consumers can handle it without Giant.
show more ...
|
#
8a412f31 |
| 14-Mar-2004 |
Peter Wemm <peter@FreeBSD.org> |
Move the process_fork event out from under Giant. This one is easy, since there are no consumers in the tree. Document this.
|
#
37814395 |
| 13-Mar-2004 |
Peter Wemm <peter@FreeBSD.org> |
Push Giant down a little further: - no longer serialize on Giant for thread_single*() and family in fork, exit and exec - thread_wait() is mpsafe, assert no Giant - reduce scope of Giant in exit to
Push Giant down a little further: - no longer serialize on Giant for thread_single*() and family in fork, exit and exec - thread_wait() is mpsafe, assert no Giant - reduce scope of Giant in exit to not cover thread_wait and just do vm_waitproc(). - assert that thread_single() family are not called with Giant - remove the DROP/PICKUP_GIANT macros from thread_single() family - assert that thread_suspend_check() s not called with Giant - remove manual drop_giant hack in thread_suspend_check since we know it isn't held. - remove the DROP/PICKUP_GIANT macros from thread_suspend_check() family - mark kse_create() mpsafe
show more ...
|
#
0235bf02 |
| 10-Mar-2004 |
John-Mark Gurney <jmg@FreeBSD.org> |
make sure we had the filedesc lock when calling fdinit when RFCFDG is set on call to rfork.
Submitted by: Brian Buchanan Semi-Reviewed by: rwatson
|
#
a69d88af |
| 08-Mar-2004 |
Peter Wemm <peter@FreeBSD.org> |
Move a vref call outside of proc locks and Giant. By virtue of the fact that we (p1) are currently running, we hold a reference on p_textvp which means the vnode cannot go away. p2 cannot run yet (
Move a vref call outside of proc locks and Giant. By virtue of the fact that we (p1) are currently running, we hold a reference on p_textvp which means the vnode cannot go away. p2 cannot run yet (and hence cannot exit) so this should be safe to do at this point. As a bonus, it removes a block of under-Giant code that was there to support the vref.
show more ...
|
#
5fadbfea |
| 07-Mar-2004 |
Alan Cox <alc@FreeBSD.org> |
Giant is not required for vm_thread_new_altkstack().
|
#
5750ee29 |
| 06-Mar-2004 |
Peter Wemm <peter@FreeBSD.org> |
Add a missing part of jhb's previous commit. It looks like he had a patch chunk rejected that he missed. This would manifest as a lock assertion panic at boot (Giant not locked in kern_fork.c).
Ob
Add a missing part of jhb's previous commit. It looks like he had a patch chunk rejected that he missed. This would manifest as a lock assertion panic at boot (Giant not locked in kern_fork.c).
Obtained from: jhb
show more ...
|
#
5ce2f678 |
| 05-Mar-2004 |
John Baldwin <jhb@FreeBSD.org> |
- Grab a share lock of the proctree lock while looking for a pid due to the process group and session dereferences. Also, check that p_pgrp and p_sesssion are NULL before dereferencing them. - P
- Grab a share lock of the proctree lock while looking for a pid due to the process group and session dereferences. Also, check that p_pgrp and p_sesssion are NULL before dereferencing them. - Push down Giant in fork1().
Requested by: peter
show more ...
|
#
c8564ad4 |
| 04-Mar-2004 |
Bruce Evans <bde@FreeBSD.org> |
Fixed some style bugs (mainly English usage errors in comments).
|
#
47934cef |
| 26-Feb-2004 |
Don Lewis <truckman@FreeBSD.org> |
Split the mlock() kernel code into two parts, mlock(), which unpacks the syscall arguments and does the suser() permission check, and kern_mlock(), which does the resource limit checking and calls vm
Split the mlock() kernel code into two parts, mlock(), which unpacks the syscall arguments and does the suser() permission check, and kern_mlock(), which does the resource limit checking and calls vm_map_wire(). Split munlock() in a similar way.
Enable the RLIMIT_MEMLOCK checking code in kern_mlock().
Replace calls to vslock() and vsunlock() in the sysctl code with calls to kern_mlock() and kern_munlock() so that the sysctl code will obey the wired memory limits.
Nuke the vslock() and vsunlock() implementations, which are no longer used.
Add a member to struct sysctl_req to track the amount of memory that is wired to handle the request.
Modify sysctl_wire_old_buffer() to return an error if its call to kern_mlock() fails. Only wire the minimum of the length specified in the sysctl request and the length specified in its argument list. It is recommended that sysctl handlers that use sysctl_wire_old_buffer() should specify reasonable estimates for the amount of data they want to return so that only the minimum amount of memory is wired no matter what length has been specified by the request.
Modify the callers of sysctl_wire_old_buffer() to look for the error return.
Modify sysctl_old_user to obey the wired buffer length and clean up its implementation.
Reviewed by: bms
show more ...
|
Revision tags: release/5.2.1_cvs, release/5.2.1 |
|
#
4c3558aa |
| 05-Feb-2004 |
John Baldwin <jhb@FreeBSD.org> |
Always set a process' state to normal when it is fully constructed in fork1() rather than only doing it for the RFSTOPPED case and then having to fix it up in other places later on.
|
#
91d5354a |
| 04-Feb-2004 |
John Baldwin <jhb@FreeBSD.org> |
Locking for the per-process resource limits structure. - struct plimit includes a mutex to protect a reference count. The plimit structure is treated similarly to struct ucred in that is is always
Locking for the per-process resource limits structure. - struct plimit includes a mutex to protect a reference count. The plimit structure is treated similarly to struct ucred in that is is always copy on write, so having a reference to a structure is sufficient to read from it without needing a further lock. - The proc lock protects the p_limit pointer and must be held while reading limits from a process to keep the limit structure from changing out from under you while reading from it. - Various global limits that are ints are not protected by a lock since int writes are atomic on all the archs we support and thus a lock wouldn't buy us anything. - All accesses to individual resource limits from a process are abstracted behind a simple lim_rlimit(), lim_max(), and lim_cur() API that return either an rlimit, or the current or max individual limit of the specified resource from a process. - dosetrlimit() was renamed to kern_setrlimit() to match existing style of other similar syscall helper functions. - The alpha OSF/1 compat layer no longer calls getrlimit() and setrlimit() (it didn't used the stackgap when it should have) but uses lim_rlimit() and kern_setrlimit() instead. - The svr4 compat no longer uses the stackgap for resource limits calls, but uses lim_rlimit() and kern_setrlimit() instead. - The ibcs2 compat no longer uses the stackgap for resource limits. It also no longer uses the stackgap for accessing sysctl's for the ibcs2_sysconf() syscall but uses kernel_sysctl() instead. As a result, ibcs2_sysconf() no longer needs Giant. - The p_rlimit macro no longer exists.
Submitted by: mtm (mostly, I only did a few cleanups and catchups) Tested on: i386 Compiled on: alpha, amd64
show more ...
|
#
6bea667f |
| 25-Jan-2004 |
Robert Watson <rwatson@FreeBSD.org> |
When aborting fork() due to a failure, if using MAC, make sure to clean up the p_label field.
Obtained from: TrustedBSD Project Sponsored by: DARPA, McAfee Research
|
#
679365e7 |
| 21-Jan-2004 |
Robert Watson <rwatson@FreeBSD.org> |
Reduce gratuitous includes: don't include jail.h if it's not needed. Presumably, at some point, you had to include jail.h if you included proc.h, but that is no longer required.
Result of: self inju
Reduce gratuitous includes: don't include jail.h if it's not needed. Presumably, at some point, you had to include jail.h if you included proc.h, but that is no longer required.
Result of: self injury involving adding something to struct prison
show more ...
|
Revision tags: release/5.2.0_cvs, release/5.2.0 |
|
#
5cded904 |
| 10-Jan-2004 |
Olivier Houchard <cognet@FreeBSD.org> |
Prevent a race condition between fork1() and whatever changes the pgrp by setting the new process' p_pgrp again before inserting it in the p_pglist. Without it we can get the new process to be insert
Prevent a race condition between fork1() and whatever changes the pgrp by setting the new process' p_pgrp again before inserting it in the p_pglist. Without it we can get the new process to be inserted in a different p_pglist than the one p2->p_pgrp points to, and this is not something we want to happen. This is not a fix, merely a bandaid, but it will work until someone finds a better way to do it.
Discussed with: jhb (a long time ago)
show more ...
|