We don't initialize the dhcp packets, so some of them get the relay agent IP
set, and the DHCP DISCOVER packets get sent to a random address on the
Internet.  Usually it doesn't have a DHCP server installed, so the guest
does not get configured.

Fix by zero-initializing the packet.

Currently, looking up a non-existing tracepoint kills the guest:

sun.org.mozilla.javascript.WrappedException: Wrapped java.lang.RuntimeException: Cannot find tracepoint (/console/perf.js#91)
	at sun.org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1786)
	at sun.org.mozilla.javascript.MemberBox.newInstance(MemberBox.java:202)
	at sun.org.mozilla.javascript.NativeJavaClass.constructSpecific(NativeJavaClass.java:284)
	at sun.org.mozilla.javascript.NativeJavaClass.construct(NativeJavaClass.java:202)
	at sun.org.mozilla.javascript.ScriptRuntime.newObject(ScriptRuntime.java:2440)
	at sun.org.mozilla.javascript.gen._console_perf_js_17._c_anonymous_7(/console/perf.js:91)
	at sun.org.mozilla.javascript.gen._console_perf_js_17.call(/console/perf.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66)
	at sun.org.mozilla.javascript.gen._console_perf_js_17._c_anonymous_10(/console/perf.js:114)
	at sun.org.mozilla.javascript.gen._console_perf_js_17.call(/console/perf.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66)
	at sun.org.mozilla.javascript.gen._console_perf_js_17._c_anonymous_1(/console/perf.js:8)
	at sun.org.mozilla.javascript.gen._console_perf_js_17.call(/console/perf.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.call1(OptRuntime.java:66)
	at sun.org.mozilla.javascript.gen.cli_js_21._c_run_sync_15(cli.js:202)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.call2(OptRuntime.java:76)
	at sun.org.mozilla.javascript.gen.cli_js_21._c_invoke_18(cli.js:223)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.callName(OptRuntime.java:97)
	at sun.org.mozilla.javascript.gen.cli_js_21._c_command_19(cli.js:237)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.callName0(OptRuntime.java:108)
	at sun.org.mozilla.javascript.gen.cli_js_21._c_main_loop_21(cli.js:290)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.optimizer.OptRuntime.callName0(OptRuntime.java:108)
	at sun.org.mozilla.javascript.gen.cli_js_21._c_script_0(cli.js:323)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:426)
	at sun.org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3178)
	at sun.org.mozilla.javascript.gen.cli_js_21.call(cli.js)
	at sun.org.mozilla.javascript.gen.cli_js_21.exec(cli.js)
	at sun.org.mozilla.javascript.Context.evaluateReader(Context.java:1142)
	at com.cloudius.cli.main.RhinoCLI.run(Unknown Source)
	at com.cloudius.cli.util.TelnetCLI.handleConnection(Unknown Source)
	at com.cloudius.cli.util.TelnetD$1.run(Unknown Source)
Caused by: java.lang.RuntimeException: Cannot find tracepoint
	at com.cloudius.trace.Tracepoint.findByName(Native Method)
	at com.cloudius.trace.Tracepoint.<init>(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
	at sun.org.mozilla.javascript.MemberBox.newInstance(MemberBox.java:194)
	... 34 more

Fix that by catching errors like "perf stat" does.

Currently we statically link to libstdc++ and libgcc_s, and also dynamically
link to the same libraries (since the payload requires them).  This causes
some symbols to be available from both the static and dynamic version.

With the resolution order change introduced by 82513d41, we can
resolve the same symbol to different addresses at different times.  This
violates the One Definition Rule, and in fact breaks std::string's
destructor.

Fix by only linking in the libraries statically.  We use ld's --whole-archive
flag to bring in all symbols, including those that may be used by the payload
but not by the kernel.

Some symbols now become duplicates; we drop our version.

Needed to link the entirety of libstdc++.a.

Needed for statically linking the entirety of libgcc_eh.a.

Reduce memory consumption so we can test in a 1GB guest.

msleep() will fault if mtx is NULL.

The test tries to acquire the write lock while the read lock is taken in the
same thread, which deadlocks.

Remove the deadlocking construct.

taskqueue_thread_enqueue expects a pointer to a pointer to the taskqueue as
context, give it that.

Currently, we perform the final fdrop() in an rcu callback, which means it
can have considerable latency.  This in turn places restrictions on
further optimizations we can do to rcu, as we need prompt close() execution.

Relax this by performing the fdrop() immediately, and only deferring the
final free().  To do this, we harden fget() so it now expects files with
positive refcounts, and make sure that after the final fdrop() refcounts
are either zero or negative.

This also makes close() take effect immediately, which fixes tst-pipe.so.

There are two spaces for event channel fields in the xen vcpu data.  They were
so far just a pad because we were not using event channels.  Name them, so we
can use it. I am also taking the opportunity to fix the tabs/spaces in the
structure.

Without this, the networking stack will ignore TSO.

Improves Java Echo test from ~2Gbps to ~5Gbps.

With Dor Laor.

Basic rcu implementation and initial user.

This patch changes fget() to no longer take gfdt_lock, using rcu instead.

For rcu.

This adds fairly basic support for rcu.

Declaring:

   mutex mtx;
   rcu_ptr<my_object> my_ptr;

Read-side:

   WITH_LOCK(rcu_read_lock) {
      const my_object* p = my_ptr.read();
      // do things with *p
      // but don't block!
   }

Write-side:

  WITH_LOCK(mtx) {
    my_object* old = my_ptr.read_by_owner();
    my_object* p = new my_object;
    // ...
    my_ptr.assign(p);
    rcu_dispose(old);  // or rcu_defer(some_func, old);
  }

This patch fixes the following bug, of CLI & memcached on two vcpus
crashing on startup. The cause of the crash is this: Java is running
two threads. One loads a new shared library (in this example, libnio.so),
and the second thread just running normally and runs some function it hasn't
run before (pthread_cond_destroy()). When our on-demand resolver code tries
to resolve this function name, it iterates over the module list, and sees
libnio.so, but this object hasn't been completely set up yet (we put it in
the list first - see program::add_object()), so looking up a symbol in it
crashes.

Why hasn't this problem been noticed before the recent link-order change?
Because before that change, the half-loaded library was always last in the
list (OSV itself was the first), so existing symbols were always found before
reaching the partially-set-up object. Now OSV, with many symbols, is last, and
the half-set-up object is in the middle, so the problem is common. But it
also could happen previously, if we had unresolved symbols (e.g., weak symbols),
but these were probably rare enough for the bug not to happen in practice.

The fix in this patch is "hacky", because I wanted to avoid restructuring
the whole code. The problem is that the functions called in add_object()
(including relocate_rela(), nested add_object(), etc.) all assume that
they can look up symbols in the being-set-up object, while we don't want
these objects to be visible for other threads. So we do exactly this -
each object gets a "visiblity" field. If "visibility" is 0, all threads
can use this object, but if visibility is a thread pointer, only this
thread searches in this object. So add_object() starts the object
with visibility set to its thread, and only when add_object() is done,
it sets the visibility to 0 so all threads can see it.

While this solves the common bug, not that this patch still leaves
a small room for SMP bugs, because it doesn't add locking to _modules,
so a lookup during an add_object() can see a broken vector for a short
duration. We should fix this remaining problem later, using RCU.

This patch fixes the exception handling bug seen in tst-except.so.

The callback given dl_iterate_phdr (such as _Unwind_IteratePhdrCallback
in libgcc_eh.a used to implement exceptions) may decide to cache previous
information we gave it, as long as the "adds" and "subs" fields are
unchanged.

The bug was that we passed to the callback a on-stack *copy* of the
obj->_phdrs vector, and if the callback saved pointers to that in its
cache, they became invalid on the next call. We need the pointers to
remain valid as long as adds/subs do not change. So we need to pass
the actual obj->_phdrs (which doesn't change after the object's load),
NOT a copy.

Note there's a locking issue remaining here - if someone dlclose()s
an object while the callback is running (and already checked adds/subs)
it can use a stale pointer. This should be fixed separately, probably
by using reference counting on objects.

The callback function passed to dl_iterate_phdr, such as
_UnWind_IteratePhdrCallback (used in libgcc_eh.a to implement exceptions),
may want to cache previous lookups, and wants to know when the list of
iterated modules hasn't changed since the last call to dl_iterate_phdr.
For this, dl_iterate_phdr() is supposed to fill two fields, dlpi_adds
and dlpi_subs, counting the number of times objects were loaded or
unloaded from the program. If both dlpi_subs and dlpi_adds are unchanged,
the callback is guaranteed the list of objects is unchanged.

In the existing code, we forgot to set these two fields, so they got
random values which caused the exception unwinding code to sometimes
cache, and sometime not cache, depending on the phase of the moon.

This patch adds the counting of the correct "subs" and "adds" counters,
and after it exception unwinding will always use its cache (as long
as the list of objects doesn't change).

Note that this does NOT fix the crash in tst-except.so. That is a bug
which appears when caching is enabled (which before this patch happend
randomly), and will be fixed by the next patch.

Our console works well with KVM, that redirects the serial to stdio. In Xen,
this seems not to work very well (some documentation sources - not all - lists
'serial="stdio"' as a valid option, but it doesn't really work). In that case,
LFs are not automatically translated into CRLF and the terminal output is totally
borked.

This is obviously not exclusive to Xen: by changing our qemu command line to run
a pts instead of stdio, and then connecting to that pts, the same thing happens.

This patch modifies our console's write() function to respect the termios ONLCR
flag, which is now set by default. When write() sees a newline character and
this flag is set we output a CF before any LF.

The termios structure is left outside the specific console, and we pass a
pointer down to it. Our pre-console implementation of simple_write outputs CRs
unconditionally.

The normal stdio serial still works. Telnet still works.

When we call render, we are still in raw mode. So we need to insert the carriage
return ourselves.

Our console write() takes 3 parameters. The last one controls whether or not we
will issue a newline at the end of input. If it is true, we will call the
console's implementation of newline(). It is always passed as false, though.
Remove it and fix the callers.

dlerror is needed when an application is started on the JVM with the
"-javaagent" option defined.

Posix doesn't require a writeable file descriptor for fsync, and all common
operating systems allow fsync on a non-writable fd, as this is required
to synchronize directory operations.

Also fix up the indentation in sys_fsync a bit.

Suggested by hch.

As pointed out by Nadav, posix_fadvise() doesn't set errno. Instead, it
returns the error number:

  http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_fadvise.html

Prevent IPIs to a cpu that is idle for a short time.

The option to undef LOCKFREE_MUTEX in osv/mutex.h, to enable the old
spin-based mutex, got broken after the addition of the wait morphing
feature.

Wait morphing needs two features which were never added to the spin-based
option, and probably never will (we should in the near future remove the
old mutex implementation): 1. The mutex->send_lock() feature, on which
the wait morphing feature is built, and 2. The ability to add another
field, "user_mutex", to condvar, which means condvar cannot be constraint
in size so libc/pthread.cc must use a pointer, which we only currently
do for the larger LOCKFREE_MUTEX.

So this patch re-adds the "WAIT_MORPHING" compile-time option, and
disables WAIT_MORPHING if LOCKFREE_MUTEX is disabled.

Now OSV can be compiled with #undef LOCKFREE_MUTEX.