(and especially, after filesystems have been unmounted).
This way, rump.halt returns once the rump kernel is really out of the
game, which avoids races issues in test scripts using a rump kernel.
OK pooka@
returning directly. This allows other threads to run possible
setting a condition we are waiting on.
Fixes a busyloop condition which could be entered from vfs_unmountall()
where we were waiting for vrele_pending and the vrele thread could
not run since we were hogging the CPU.
should generate the right info, but it's easier to fix here now.
This fixes compat syscalls for rump servers with dynamically loaded
components. Since the compat syscall revamp a little time ago e.g.
stat() didn't work on my system (which is 5.0-based) with e.g.
rump_server -lrumpvfs. Static servers and non-compat syscalls
worked just fine, though, making this a little harder to spot that
the usual bug.
in the socket before we shut down. This way the response to the
syscall travels to the caller and they know things worked correctly
instead of having to just assume.
necessary for rump.
XXX: strictly speaking, the zfs implementation does not work
correctly since it just wakes up a thread instead of performing
the scan in the context of the pagedaemon
if it has enough memory available, just pick a number which makes
zfs happy.
We *could* use a MIN() of available host mem and rump_memlimit,
though ...
some locking and rumpcopy primitives and refactor module building Makefiles
to work with both RUMP and kernel modules. This is first part of adding
support for regular test of zfs on NetBSD to hunt some bugs and make it
stable.
Ok by pooka@.
threads blocking in the kernel automatically exit when the process
exists. However, for the sysproxy case this does not hold.
Typically it's ~harmless, but e.g. in the case of socket binding
following by poll it gets annoying.
Introduce sysproxy procexit, which wakes up all threads blocking
on a condition when a process's communication socket is closed.
The code is a little different from the regular kernel simply
because in a rump kernel l_mutex is not available at all times
(this is because scheduling happens on every kernel entry and exit,
and that path must be kept lockless for any reasonable performance).
Instead, use gating which makes sure all threads are either out of
the cv code or suspended in a well-known state. Then, wake up the
threads and tell them to get the hell out of our galaxy.
It is executed after IF and the purposes to guarantee the right
order in cross-component interface address configuration.
(e.g. lo0 is attached by net but 127.0.0.1 is configured by netinet)
relevant, so to accommodate that change rump_lwproc_newproc() to
rump_lwproc_rfork(). The new interface has the rfork() fd table
semantics. The equivalent of rump_lwproc_newproc() is
rump_lwproc_rfork(RUMP_RFCFDG).
syscalls provided by a rump faction such as rumpvfs when the library
is not linked into the binary, but is dlopen()'d before calling
rump_init().
(it is illegal to dlopen() a faction after rump_init(), but syscalls
maybe be added the usual way with modules)
rump_server(1) -lstuff works now.
desired values in case the components containing the netisr handlers
were not linked in but dlopen()'d before calling rump_init().
(could simplify a little in case static linking is declared dead)
that scheduler locks are special in this regard - adaptive locks cannot
be in the path due to turnstiles. Randomly spotted/reported by uebayasi@.
- Remove unused lwp_relock() and replace lwp_lock_retry() by simplifying
lwp_lock() and sleepq_enter() a little.
- Give alllwp its own cache-line and mark lwp_cache pointer as read-mostly.
OK ad@
lock any uvm objects, check if lockholders are currently on CPU
and yield to try very soon again instead of assuming deadlock.
This makes limited-memory kernels perform the same as memory-unlimited
kernels (provided there is a reasonable amount of memory available).
For example, for large file copy off of ffs where the image is
backed on host memory (i.e. no disk i/o, i.e. ideal conditions)
the figures are, per rump kernel memory limit:
3000kB: same
1000kB: 10% slower
500kB: 50% slower
(per pagedaemon code might still be able to use some tweak, though)
is done in rumpuser for simplicity, since on the kernel side things
we assume we have only one pointer of space). As a side-effect,
we can no longer know if the current thread is holding on to a
mutex locked without curlwp context (basically all mutexes inited
outside of mutex_init()). The only thing that called rumpuser_mutex_held()
for a non-kmutex was the giant lock. So, instead implement recursive
locking for the giant lock in the rump kernel and get rid of the
now-unused recursive pthread mutex in the hypercall interface.
satisfied. This allows the caller to unlock the object and the
pagedaemon to avoid deadlock even if ~all memory is consumed by
one vm object. This in turn makes is possible to copy a large file
into a rump kernel with a 10MB memory limit (where large >> 10MB).
A little more tuning will be required to avoid the pagedaemon
hitting the sleep-and-retry path, though.
+ fix some outdated unrelated comments
Also, add rump_daemonize_begin() / rump_daemonize_end() to help
with the "can't daemon() after pthread_create()" problem. Applications
could accomplish the same, but since it's such a common operation,
provide a little help.
etfs objects must now be registered as absolute paths; however, it is now
possible to access them via relative paths and through symlinks, which
previously worked some times and not others depending on exactly what
namei was doing.
discussed on tech-kern and ok'd by pooka.
Now, let's say you start a rump server and configure a memory disk
on it. Remote (as in TCP remote) clients may now access that
memory.
cloudy, my apps are scattered and they're cloudy
they have no borders, no boundaries
==> add support for remote vmspace vmapbuf/vunmapbuf
==> add proper support for copyin/out_vmspace
==> add support for remote vmspace uvm_io
==> add support for non-curproc rumpuser_sp_copyin/out
==> store remote context in vm_map->pmap instead of
pthread_specificdata
In short, makes read/write of most (all?) block devices work from
a remote rump client via rump syscalls.
and the metadata required to interpret it. Callers of namei must now
create a pathbuf and pass it to NDINIT (instead of a string and a
uio_seg), then destroy the pathbuf after the namei session is
complete.
Update all namei call sites accordingly. Add a pathbuf(9) man page and
update namei(9).
The pathbuf interface also now appears in a couple of related
additional places that were passing string/uio_seg pairs that were
later fed into NDINIT. Update other call sites accordingly.
pooka