making it even more stressful ;)

the atomic operations in atomic.h weren't really atomic. this is
something that was missed in the netport and now fixed.

ZFS wants direct access to a global utsname structure.  Provide one from
core OSv code and rewrite uname to just copy it out.  To ease this move
the uname implementation to a C file as this allows using designated
initializers and avoids the casting mess around memcpy.

the debug() console function is taking a lock before it access the console driver,
it does that by acquiring a mutex which may sleep.

since we want to be able to debug (and abort) in contexts where it's not possible sleep,
such as in page_fault, a lockless debug print method is introduced.

previousely to this patch, any abort on page_fault would cause an "endless" recursive
abort() loop which hanged the system in a peculiar state.

the current code handles the case of recursive aborts incorrectly, while
the existing comment is very precise :)

This allows to remove various #if 0'ed code using vnode_t or znode_t to be
compiled, both in the current headers and future ported code.

BSD and Solaris code likes to pass this identifier for the "kernel" process
to various thread creation routines.  Make our life simpler by providing it
and ignoring it.

The comment about unlocking the irq_lock was put on the wrong line.
Move it (and rephrase it a bit - the word "release" immediately after
calling an unrelated release() function - is confusing).

yield() had two bugs - thanks to Avi for pinpointing them:

1. It used runqueue.push_back() to put the thread on the run queue, but
   push_back() is a low-level function which can only be used if we're
   sure that the item we're pushing has the vruntime suitable for being
   *last* on the queue - and in the code we did nothing to ensure this
   is the case (we should...). So use insert_equal(), not push_back().

2. It was wrongly divided into two separate sections with interrupts
   disabled. The scheduler code is run both at interrupt time (e.g.,
   preempt()) and at thread time (e.g., wait(), yield(), etc.) so to
   guarantee it does not get called in the middle of itself, it needs
   to disable interrupts while working on the (per-cpu) runqueue.
   In the broken yield() code, we disabled interupts while adding the
   current thread to the run queue, and then again to reschedule.
   Between those two critical sections, an interrupt could arrive and
   do something with this thread (e.g., migrate it to another CPU, or
   preempt it), yet when the interrupt returns yield continues to run
   reschedule_from_interrupt which assumes that this thread is still
   running, and definitely not on the run queue.

Bug 2 is what caused the crashes in the tst-yield.so test. The fix is
to hold the interrupts disabled throughout the entire yield().
This is easiest done with with lock_guard, which simplifies the flow
of this function.

Because of Linux's calling convention, it should not be necessary to
save the FPU state when a reschedule is caused by a function call.

Because we had a bug and forgot to save the FPU state when calling
a signal handler, and because this signal handler can cause a reschedule,
we had to save the FPU on any reschedule. But after fixing that bug, we
no longer need these unnecessary FPU saves.

The "sunflow" benchmark still runs well after this patch.

If interrupts are disabled, we must not call schedule() even if
the preemption counter says we need to, as the context is not preemption
safe.

This manifested itself in a wake() within a timer causing a schedule(),
which re-enabled interrupts, which caused further manipulation of the timer
list to occur concurrently with the next interrupt, resulting in corruption.

Fixes timer stress test failure.

noticed an assert in the download file test that was related to timers,
this test reproduce the same bug.

This patch adds missing FPU-state saving when calling signal handlers.
The state is saved on the stack, to allow nesting of signal handling
(delivery of a second signal while a first signal's handler is running).

In Linux calling conventions, the FPU state is caller-saved, i.e., a
called function can use FPU at will because the caller is assumed to have
saved it if needed. However, signal handlers are called asynchronously,
possibly in the middle of some FPU computation without that computation
getting a chance to save its state. So we must save this state before calling
the signal handling function.

Without this fix, we had problems even if the signal handlers themselves
did not use the FPU. A typical scenario - which we encountered in the
"sunflow" benchmark - is that the signal handler does something which uses
a mutex (e.g., malloc()) and causes a reschedule. The reschedule, not a
preempt(), thinks it does not need to save the FPU state, and the thread
we switch to clobbers this state.

now it downloads a ~200MB file and validating md5 on it.

the old implementation used threads for dispatching callouts, each callout
owned a thread and it suffered from a race where a callout structure could have
been deleted before the callout thread even begun.

the current implementation is dispatching all callouts in a single callout
dispatcher thread, it maintains an ordered list of callouts to achieve that.

this patch solve a crash with the TCPDownloadFile test, that now proceeds.

the mbuf ext buffer is freed in the dtor, so it should be called before finit.
this is fixing a crash that surfaced by using the conf-memory-debug=1

this haven't caused a real bug, I just noticed it while tracing.
it may be dangerous if in some flow, the stack will not be zeroed

strerror_r is needed by the JVM in order to print errors correctly.

A todo item to avoid unnecessary fpu state saving

Things we still need to do to use the lockfree mutex

Following an idea raised during our last discussion on TODOs, I committed
a new directory "todo/", and one file in it, todo/mm, with TODOs and ideas
for memory management.

I suggest that we allow free commits to this directory - with no overhead
of "review" of these informal todo items.

If we decide we don't like this format, we can easily move the content of
these files to some other tool or database or whatever.