rump tcp/ip stack:
* sshd likes to fork and then re-exec itself
==> trap execve() and augment the env with the current parameters
essential to a rump kernel (kernel communication fd, information
about dup2'd file descriptors)
* sshd likes to play lots of games with pipes, socketpairs and dup{,2}()
==> make sure we do not close essential rump client descriptors:
dup() them to a safe place, except for F_CLOSEM where we
simply leave them alone. also, partially solved by the above,
make sure the process's set of rump kernel descriptors persists
over exec()
* sshd likes to chdir() before exec
==> for unix-style rump_sp(7) sockets save the full path on the
initial exec and use it afterwards. thread the path through
the environment in execve()
expired it would assume that all input set descriptors had activity.
In case we get rv == 0 from the poll backend, zero out the fd sets
to signal that in fact no descriptors have activity.
Before this commit ssh was "jittery" when run through a rump tcp/ip
stack (interactive sessions kept blocking on stdin and you had to
"peddle" the connection). Now it works smoothly ... or at least
smoothly enough so that this commit could be done through a rump
tcp/ip stack:
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root ssh 125 0 tcp localhost.65517 cvs.netbsd.org.22
TCP/IP stack:
* mutt prepares to exec the smtp client: it forks and closes all
file descriptors
* when the next networking syscall is done, rumpclient detects that
the communication fd returned EBADF and does a reconnect,
gets descriptor 0 for the socket and descriptor 1 for kqueue
* mutt opens the mail file and implicitly assumes it'll get 0-2,
but in fact gets 2-4
* mutt execs the smtp agent which tries to read the mail from
stdin (rumpclient communication socket) and fails
Even if mutt correctly did dup2() things would go south when trying
to communicate with the kernel server the next time, since rumpclient
would actually be talking with some mail body instead (well, it
could work, but in that case you'd need to write *really* weird
mails ;).
Hence, prevent rumpclient from using the special fd's 0-2 for its
purposes.
Should fix mutt problem reported by Alexander Nasonov.
libc resolver uses it. Error out in case of rump fd kevent (TODO).
Fixes one more problem pointed out by Alexander Nasonov.
Also, implement dup().
(TODO: implement it along the fcntl path too)
to access, manage and manipulate device-mapper driver. Which opens us bunch
of new possibilities like
dm-multipath device target
dm-crypt device target
dm-ccd compatibility layer
With this import I'm bringing in dmctl tool for working with dm driver ,too.
I plan to replace gpl2 licensed dmsetup command with our dmctl tool in near
feature. It can also by placed to /rescue where we was not able to put
dmsetup because of licensing problems.
With libdm in tree we can now write RUMP atf test suite for dm driver to
ensure LVM subsystem stability as time goes.
Reviewed by: blymn@ and rmind@
Oked: by no objections on tech-userlevel@
it. I still don't have any idea what the ssp stuff is supposed to
do and how it's supposed to even begin to work. If someone wants
to change this now, run tests/lib/librumphijack before commit so
that I can avoid another multihour debugging session!
a wedge. This still lacks the proplibistic query of the sector
size and just assumes 512. It's good that we make asking a file's
size as simple as requiring one stat(), one open() and three (3)
different ioctls plus some proplist mumbojumbo. I'm surprised it's
available at all by means other than #wish.
code mostly from Taylor R Campbell, rant from me.
two or more syscall requests before any worker thread ran, we might
not have enough threads to handle the requests. In some scenarios
this could lead to a deadlock.
christos