Make context switching much more MI:
- Move the functionality of choosing a process from cpu_switch into
a much simpler function: cpu_switchto. Instead of having the locore
code walk the run q

Make context switching much more MI:
- Move the functionality of choosing a process from cpu_switch into
a much simpler function: cpu_switchto. Instead of having the locore
code walk the run queues, let the MI code choose the process we
want to run and only implement the context switching itself in MD
code.
- Let MD context switching run without worrying about spls or locks.
- Instead of having the idle loop implemented with special contexts
in MD code, implement one idle proc for each cpu. make the idle
loop MI with MD hooks.
- Change the proc lists from the old style vax queues to TAILQs.
- Change the sleep queue from vax queues to TAILQs. This makes
wakeup() go from O(n^2) to O(n)

there will be some MD fallout, but it will be fixed shortly.
There's also a few cleanups to be done after this.

deraadt@, kettenis@ ok

show more ...

Back out the tracking of procs in struct selinfo. There's one serious
bug in the code, but as soon as I try to fix it, it seems to trigger
some other bugs. Instead of trying to figure out what's goin

Back out the tracking of procs in struct selinfo. There's one serious
bug in the code, but as soon as I try to fix it, it seems to trigger
some other bugs. Instead of trying to figure out what's going on
while everyone suffers, it's better to back out and figure out
the bugs outside the tree.

show more ...

The world of __HAVEs and __HAVE_NOTs is reducing. All architectures
have cpu_info now, so kill the option.

eyeballed by jsg@ and grange@

move p_limit and p_cred into struct process
leave macros behind for now to keep the commit small
ok art beck miod pedro

Start moving state that is shared among threads in a process into
a new struct. Instead of doing a huge rename and deal with the fallout
for weeks, like other projects that need no mention, we will s

Start moving state that is shared among threads in a process into
a new struct. Instead of doing a huge rename and deal with the fallout
for weeks, like other projects that need no mention, we will slowly and
carefully move things out of struct proc into a new struct process.

- Create struct process and the infrastructure to create and remove them.
- Move threads in a process into struct process.

deraadt@, tedu@ ok

show more ...

Kill the horrible hack of storing the pid in struct selinfo.

Instead, keep the proc pointer in it and put the selinfo on a list
in struct proc in selrecord. Then clean up the list when leaving
sys_s

Kill the horrible hack of storing the pid in struct selinfo.

Instead, keep the proc pointer in it and put the selinfo on a list
in struct proc in selrecord. Then clean up the list when leaving
sys_select and sys_poll.

miod@ ok, testing by many, including Bobs spamd boxes.

show more ...

Since p_flag is often manipulated in interrupts and without biglock
it's a good idea to use atomic.h operations on it. This mechanic
change updates all bit operations on p_flag to atomic_{set,clear}b

Since p_flag is often manipulated in interrupts and without biglock
it's a good idea to use atomic.h operations on it. This mechanic
change updates all bit operations on p_flag to atomic_{set,clear}bits_int.

Only exception is that P_OWEUPC is set by MI code before calling
need_proftick and it's automatically cleared by ADDUPC. There's
no reason for MD handling of that flag since everyone handles it the
same way.

kettenis@ ok

show more ...

reintroduce rev 1.83 -- put the new process on the proc lists
later when more of it's resources have been allocated and thus
kill(2)ing such a process has more predictable results.
now w/ a couple of

reintroduce rev 1.83 -- put the new process on the proc lists
later when more of it's resources have been allocated and thus
kill(2)ing such a process has more predictable results.
now w/ a couple of kettenis remarks; kettenis@ miod@ ok

show more ...

Kernel stack can be swapped. This means that stuff that's on the stack
should never be referenced outside the context of the process to which
this stack belongs unless we do the PHOLD/PRELE dance. Lo

Kernel stack can be swapped. This means that stuff that's on the stack
should never be referenced outside the context of the process to which
this stack belongs unless we do the PHOLD/PRELE dance. Loads of code
doesn't follow the rules here. Instead of trying to track down all
offenders and fix this hairy situation, it makes much more sense
to not swap kernel stacks.

From art@, tested by many some time ago.

show more ...

Backout last commit, it makes us crash when a ptraced program forks.

do not rush putting embrionic process on child/thread/sibling lists and set timeouts earlier as we can sleep later and get signals and exit and cause all kinds of hell; pedro@ ok

Compile out more rthreads stuff unless option RTHREADS;
discussed with a few, ok tedu@

fix memory leak conditions in thrsleep and significantly simplify

forgot to set P_THREAD for threaded processes

kernel support for threaded processes (rthreads).
uses rfork(RFTHREAD) to create threads, which are presently processes
that are a little more tightly bound together. several new syscalls
added to f

kernel support for threaded processes (rthreads).
uses rfork(RFTHREAD) to create threads, which are presently processes
that are a little more tightly bound together. several new syscalls
added to facilitate a userland thread library.
all conditional on RTHREADS, currently disabled.
ok deraadt

show more ...

Avoid a theoretical race condition.

In fork1(), setup the p_{prof,virt}_to timeouts _before_ putting the process
on the runqueue. Since SCHED_UNLOCK() can cause pre-emption, it is possible
(with th

Avoid a theoretical race condition.

In fork1(), setup the p_{prof,virt}_to timeouts _before_ putting the process
on the runqueue. Since SCHED_UNLOCK() can cause pre-emption, it is possible
(with the old code) for the newly created process to run and become curproc
before the timeouts were set. If itimers are set early, and you're unlucky,
hardclock() might fire at this time and attempt timeout_add() on the unset
timeouts, leading to "panic: timeout_add: not initialized".

deraadt@, miod@ ok

show more ...

ptrace(2) following fork(2)
ok miod@

sched work by niklas and art backed out; causes panics

This patch is mortly art's work and was done *a year* ago. Art wants to thank
everyone for the prompt review and ok of this work ;-) Yeah, that includes me
too, or maybe especially me. I am sorry.

This patch is mortly art's work and was done *a year* ago. Art wants to thank
everyone for the prompt review and ok of this work ;-) Yeah, that includes me
too, or maybe especially me. I am sorry.

Change the sched_lock to a mutex. This fixes, among other things, the infamous
"telnet localhost &" problem. The real bug in that case was that the sched_lock
which is by design a non-recursive lock, was recursively acquired, and not
enough releases made us hold the lock in the idle loop, blocking scheduling
on the other processors. Some of the other processors would hold the biglock though,
which made it impossible for cpu 0 to enter the kernel... A nice deadlock.
Let me just say debugging this for days just to realize that it was all fixed
in an old diff noone ever ok'd was somewhat of an anti-climax.

This diff also changes splsched to be correct for all our architectures.

show more ...

fix pr4036, don't set p2->p_cpu to null
ok deraadt miod markus

Create the init process earlier, before the root filesystem is mounted,
and have it stall on a semaphore. This allows all kthread creations which
could have been requested during autoconf to be proce

Create the init process earlier, before the root filesystem is mounted,
and have it stall on a semaphore. This allows all kthread creations which
could have been requested during autoconf to be processed before root
is mounted as well.

This causes umass devices attached to any usb with flags 1 (such as on macppc)
to configure properly instead of panicing the kernel at mountroot time.

From NetBSD; tested by various.

show more ...

provide md USPACE_ALIGN zero on all but mips; deradat@ pefo@ ok

hardclock detects if ITIMER_VIRTUAL and ITIMER_PROF have expired and
sends SIGVTALRM and SIGPROF to the process if they had. There is a big
problem with calling psignal from hardclock on MULTIPROCESS

hardclock detects if ITIMER_VIRTUAL and ITIMER_PROF have expired and
sends SIGVTALRM and SIGPROF to the process if they had. There is a big
problem with calling psignal from hardclock on MULTIPROCESSOR machines
though. It means we need to protect all signal state in the process
with a lock because hardclock doesn't obtain KERNEL_LOCK. Trying to
track down all the tentacles of this quickly becomes very messy. What
saves us at the moment is that SCHED_LOCK (which is used to protect
parts of the signal state, but not all) happens to be recursive and
forgives small and big errors. That's about to change.

So instead of trying to hunt down all the locking problems here, just
make hardclock not send signals. Instead hardclock schedules a timeout
that will send the signal later. There are many reasons why this works
just as good as the previous code, all explained in a comment written
in big, friendly letters in kern_clock.

miod@ ok noone else dared to ok this, but noone screamed in agony either.

show more ...

This moves access to wall and uptime variables in MI code,
encapsulating all such access into wall-defined functions
that makes sure locking is done as needed.

It also cleans up some uses of wall ti

This moves access to wall and uptime variables in MI code,
encapsulating all such access into wall-defined functions
that makes sure locking is done as needed.

It also cleans up some uses of wall time vs. uptime some
places, but there is sure to be more of these needed as
well, particularily in MD code. Also, many current calls
to microtime() should probably be changed to getmicrotime(),
or to the {,get}microuptime() versions.

ok art@ deraadt@ aaron@ matthieu@ beck@ sturm@ millert@ others
"Oh, that is not your problem!" from miod@

show more ...

debranch SMP, have fun