When some code section happens to be called from both thread context and
interrupt context, and we need mutual exclusion (we don't want the interrupt
context to start while the critical section is in the middle of running in
thread context), we surround the critical code section with CLI and STI.

But we need the compiler to assure us that writes to memory done between
the calls to CLI and STI stay between them. For example, if we have

    thread context:                 interrupt handler:

      CLI;                          a--;
      a++;
      STI;

We don't want the a++ to be moved by the compiler before the CLI. We also
don't want the compiler to save a's value in a register and only actually
write it back to the memory location 'a' after the STI (when an interrupt
handler might be concurrently writing). We also don't want the compiler
to remember a's last value in a register and use it again after the next
CLI.

To ensure these things, we need the "memory clobber" option on both the CLI
and STI instructions. The "volatile" keyword is not enough - it guarantees
that the instruction isn't deleted or moved, but not that stuff that
should have been in memory isn't just in registers.

Note that Linux also has these memory clobbers on sti() and cli().
Linus Torvals explains in a post from 1996 why these were necessary:
http://lkml.indiana.edu/hypermail/linux/kernel/9605/0214.html

All that being said, we never noticed a bug caused by the missing
"memory" clobbers. But better safe than sorry....

the new test creates several thread, each is downloading a ~280MB file
concurrently. It aims to find concurrency bugs in the netport, dead locks,
etc... but (fortunately) it pass.

Optimize fsbase reload using the wrfsbase instruction, where available.

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.

Drops context switch time by ~80ns.

Faster way to write fsbase on newer processors.

This are used to support ifunc functions, which are resolved at load-time
based on cpu features, rather than at link time.

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.