#
1d9c5696 |
| 01-Oct-2002 |
Juli Mallett <jmallett@FreeBSD.org> |
Back our kernel support for reliable signal queues.
Requested by: rwatson, phk, and many others
|
#
1226f694 |
| 30-Sep-2002 |
Juli Mallett <jmallett@FreeBSD.org> |
First half of implementation of ksiginfo, signal queues, and such. This gets signals operating based on a TailQ, and is good enough to run X11, GNOME, and do job control. There are some intricate p
First half of implementation of ksiginfo, signal queues, and such. This gets signals operating based on a TailQ, and is good enough to run X11, GNOME, and do job control. There are some intricate parts which could be more refined to match the sigset_t versions, but those require further evaluation of directions in which our signal system can expand and contract to fit our needs.
After this has been in the tree for a while, I will make in kernel API changes, most notably to trapsignal(9) and sendsig(9), to use ksiginfo more robustly, such that we can actually pass information with our (queued) signals to the userland. That will also result in using a struct ksiginfo pointer, rather than a signal number, in a lot of kern_sig.c, to refer to an individual pending signal queue member, but right now there is no defined behaviour for such.
CODAFS is unfinished in this regard because the logic is unclear in some places.
Sponsored by: New Gold Technology Reviewed by: bde, tjr, jake [an older version, logic similar]
show more ...
|
#
71fad9fd |
| 11-Sep-2002 |
Julian Elischer <julian@FreeBSD.org> |
Completely redo thread states.
Reviewed by: davidxu@freebsd.org
|
Revision tags: release/4.6.2_cvs, release/4.6.2, release/4.6.1 |
|
#
9f189ade |
| 18-Jul-2002 |
Julian Elischer <julian@FreeBSD.org> |
Clear up confusion in ugly code. ^T gave wrong results for RSS. I misinterpretted this code when changing it to handle threads. (there are still issues here) Submitted by: Ian Dowse <iedowse@maths.t
Clear up confusion in ugly code. ^T gave wrong results for RSS. I misinterpretted this code when changing it to handle threads. (there are still issues here) Submitted by: Ian Dowse <iedowse@maths.tcd.ie>
show more ...
|
Revision tags: release/4.6.0_cvs |
|
#
e602ba25 |
| 29-Jun-2002 |
Julian Elischer <julian@FreeBSD.org> |
Part 1 of KSE-III
The ability to schedule multiple threads per process (one one cpu) by making ALL system calls optionally asynchronous. to come: ia64 and power-pc patches, patches for gdb, test pro
Part 1 of KSE-III
The ability to schedule multiple threads per process (one one cpu) by making ALL system calls optionally asynchronous. to come: ia64 and power-pc patches, patches for gdb, test program (in tools)
Reviewed by: Almost everyone who counts (at various times, peter, jhb, matt, alfred, mini, bernd, and a cast of thousands)
NOTE: this is still Beta code, and contains lots of debugging stuff. expect slight instability in signals..
show more ...
|
#
99568bca |
| 20-Jun-2002 |
Ian Dowse <iedowse@FreeBSD.org> |
Display the mutex name in the ^T status line if the selected thread is blocked on a mutex. Prepend a '*' to distinguish this case as is done in top(1).
|
#
7aa57dca |
| 31-May-2002 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Nit: kern.ttys is of type S,xtty, not S,tty.
|
#
6b658142 |
| 28-May-2002 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Add some checks to prevent NULL dereferences.
Submitted by: jhay
|
#
6c533ac7 |
| 28-May-2002 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Add NAI copyright.
|
#
1a149fcd |
| 28-May-2002 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Introduce struct xtty, used when exporting tty information to userland. Make kern.ttys export a struct xtty rather than struct tty. Since struct tty is no longer exposed to userland, remove the dev_
Introduce struct xtty, used when exporting tty information to userland. Make kern.ttys export a struct xtty rather than struct tty. Since struct tty is no longer exposed to userland, remove the dev_t / udev_t hack.
Sponsored by: DARPA, NAI Labs
show more ...
|
#
4b4c18f8 |
| 25-May-2002 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
ANSIfy (significant portions were already partly ANSIfied)
|
#
b7457aab |
| 25-May-2002 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Remove register.
|
#
dedf14f5 |
| 25-May-2002 |
Dag-Erling Smørgrav <des@FreeBSD.org> |
Automated whitespace cleanup.
|
#
e649887b |
| 06-May-2002 |
Alfred Perlstein <alfred@FreeBSD.org> |
Make funsetown() take a 'struct sigio **' so that the locking can be done internally.
Ensure that no one can fsetown() to a dying process/pgrp. We need to check the process for P_WEXIT to see if it
Make funsetown() take a 'struct sigio **' so that the locking can be done internally.
Ensure that no one can fsetown() to a dying process/pgrp. We need to check the process for P_WEXIT to see if it's exiting. Process groups are already safe because there is no such thing as a pgrp zombie, therefore the proctree lock completely protects the pgrp from having sigio structures associated with it after it runs funsetownlst.
Add sigio lock to witness list under proctree and allproc, but over proc and pgrp.
Seigo Tanimura helped with this.
show more ...
|
#
f1320723 |
| 01-May-2002 |
Alfred Perlstein <alfred@FreeBSD.org> |
Redo the sigio locking.
Turn the sigio sx into a mutex.
Sigio lock is really only needed to protect interrupts from dereferencing the sigio pointer in an object when the sigio itself is being destr
Redo the sigio locking.
Turn the sigio sx into a mutex.
Sigio lock is really only needed to protect interrupts from dereferencing the sigio pointer in an object when the sigio itself is being destroyed.
In order to do this in the most unintrusive manner change pgsigio's sigio * argument into a **, that way we can lock internally to the function.
show more ...
|
#
596325f1 |
| 16-Apr-2002 |
John Baldwin <jhb@FreeBSD.org> |
- Lock proctree_lock instead of pgrpsess_lock. - Use temporary variables to hold a pointer to a pgrp while we dink with it while not holding either the associated proc lock or proctree_lock. It
- Lock proctree_lock instead of pgrpsess_lock. - Use temporary variables to hold a pointer to a pgrp while we dink with it while not holding either the associated proc lock or proctree_lock. It is in theory possible that p->p_pgrp could change out from under us.
show more ...
|
#
12c79eb2 |
| 03-Apr-2002 |
Ruslan Ermilov <ru@FreeBSD.org> |
Dike out a highly insecure UCONSOLE option. TIOCCONS must be able to VOP_ACCESS() /dev/console to succeed.
Obtained from: OpenBSD
|
#
2a60b9b9 |
| 02-Apr-2002 |
Seigo Tanimura <tanimura@FreeBSD.org> |
Fix leakage of p_pgrp lock.
|
#
44731cab |
| 01-Apr-2002 |
John Baldwin <jhb@FreeBSD.org> |
Change the suser() API to take advantage of td_ucred as well as do a general cleanup of the API. The entire API now consists of two functions similar to the pre-KSE API. The suser() function takes
Change the suser() API to take advantage of td_ucred as well as do a general cleanup of the API. The entire API now consists of two functions similar to the pre-KSE API. The suser() function takes a thread pointer as its only argument. The td_ucred member of this thread must be valid so the only valid thread pointers are curthread and a few kernel threads such as thread0. The suser_cred() function takes a pointer to a struct ucred as its first argument and an integer flag as its second argument. The flag is currently only used for the PRISON_ROOT flag.
Discussed on: smp@
show more ...
|
#
4d77a549 |
| 19-Mar-2002 |
Alfred Perlstein <alfred@FreeBSD.org> |
Remove __P.
|
#
85f190e4 |
| 14-Mar-2002 |
Alfred Perlstein <alfred@FreeBSD.org> |
Fixes to make select/poll mpsafe.
Problem: selwakeup required calling pfind which would cause lock order reversals with the allproc_lock and the per-process filedesc lock. Solution: Instead of
Fixes to make select/poll mpsafe.
Problem: selwakeup required calling pfind which would cause lock order reversals with the allproc_lock and the per-process filedesc lock. Solution: Instead of recording the pid of the select()'ing process into the selinfo structure, actually record a pointer to the thread. To avoid dereferencing a bad address all the selinfo structures that are in use by a thread are kept in a list hung off the thread (protected by sellock). When a selwakeup occurs the selinfo is removed from that threads list, it is also removed on the way out of select or poll where the thread will traverse its list removing all the selinfos from its own list.
Problem: Previously the PROC_LOCK was used to provide the mutual exclusion needed to ensure proper locking, this couldn't work because there was a single condvar used for select and poll and condvars can only be used with a single mutex. Solution: Introduce a global mutex 'sellock' which is used to provide mutual exclusion when recording events to wait on as well as performing notification when an event occurs.
Interesting note: schedlock is required to manipulate the per-thread TDF_SELECT flag, however if given its own field it would not need schedlock, also because TDF_SELECT is only manipulated under sellock one doesn't actually use schedlock for syncronization, only to protect against corruption.
Proc locks are no longer used in select/poll.
Portions contributed by: davidc
show more ...
|
#
183ccde6 |
| 11-Mar-2002 |
Seigo Tanimura <tanimura@FreeBSD.org> |
Stop abusing the pgrpsess_lock.
|
#
92c914f9 |
| 02-Mar-2002 |
Seigo Tanimura <tanimura@FreeBSD.org> |
Fix lock leakage and late unlock.
Submitted by: bde
|
#
e9be968e |
| 24-Feb-2002 |
Poul-Henning Kamp <phk@FreeBSD.org> |
Fix a typo (?) in previous commit told ttyprintf() to print the integer part of the user-time as a 64bit quantity. This resulted in weird output from SIGINFO.
|
#
f591779b |
| 23-Feb-2002 |
Seigo Tanimura <tanimura@FreeBSD.org> |
Lock struct pgrp, session and sigio.
New locks are:
- pgrpsess_lock which locks the whole pgrps and sessions, - pg_mtx which protects the pgrp members, and - s_mtx which protects the session member
Lock struct pgrp, session and sigio.
New locks are:
- pgrpsess_lock which locks the whole pgrps and sessions, - pg_mtx which protects the pgrp members, and - s_mtx which protects the session members.
Please refer to sys/proc.h for the coverage of these locks.
Changes on the pgrp/session interface:
- pgfind() needs the pgrpsess_lock held.
- The caller of enterpgrp() is responsible to allocate a new pgrp and session.
- Call enterthispgrp() in order to enter an existing pgrp.
- pgsignal() requires a pgrp lock held.
Reviewed by: jhb, alfred Tested on: cvsup.jp.FreeBSD.org (which is a quad-CPU machine running -current)
show more ...
|