VM used to call sendrec to send a boot-time RS_INIT reply to RS, but
RS could run into a pagefault at the same time, thus spawning a
message to VM, resulting in a deadlock. We resolve this situation by
making VM acknowledge RS_INIT asynchronously at boot time, while
retaining the synchronous sendrec for subsequent RS_INIT responses.
The following services have been updated to support stateful restarts:
- Drivers: tty
- Filesystems: isofs, mfs, pfs, libvtreefs-based file servers
- System servers: tty, ds, pm, vfs, vm
Previously, RS would clean up dead services only when it is idle.
During shutdown, all services are marked with the 'exiting' flag,
and these flags lead RS to conclude it is not idle. Therefore, at
shutdown time, no services were cleaned up anymore, leading to
deadlock situations. For example, VFS could end up waiting for a
service that was already dead, or one driver could end up waiting
for an interrupt on a line shared with another dead driver.
While it may be possible to ignore RS_EXITING when checking idle
status, other flags may have the same ultimate effect. Therefore,
this patch skips the idle check altogether when in shutdown mode.
While in a multicomponent live update that includes RS, the new RS
instance may receive heartbeat replies which, after a rollback, the
old RS instance will then never see. As a result, the rolled-back
RS instance may end up killing well-behaving services.
Some select queries require a response from device drivers. If a
select call is nonblocking (with a zero timeout), the response to
the caller may have to be deferred until all involved drivers have
responded to the initial query. This is handled just fine.
However, if the select call has a timeout that is so short that it
triggers before all the involved drivers have responded, the
resulting alarm would be discarded, possibly resulting in the call
blocking forever. This fix changes the alarm handler such that if
the alarm triggers too early, the select call is further handled
as though it was nonblocking.
This fix resolves a test77 deadlock on really slow systems.
- ping(1) triggers warnings about unimplemented exceptions for select;
even if there could be a useful implementation (which is doubtful),
the warnings are not helping anyone right now;
- the clock_t data type has changed.
Fix /dev/tty-related issues in tmux(1) by hardcoding the PTY major
in VFS in addition to the TTY major. Even though this is exactly
what we did NOT want to have to do, the actual fix for this issue
is going to take a little longer.
The previous approach of storing pointers to messages structures for
thread-blocking sendrec operations relied on several assumptions,
which if violated could lead to odd cases of memory corruption.
With this patch, VFS resets pointers right after use, avoiding that
any dangling pointers are accidentally dereferenced later. This
approach was already used in some cases, but not all of them.
For dynamically linked executables, the interpreter is passed a
file descriptor of the binary being executed. To this end, VFS
opens the target executable, but opening the file fails if it is
not readable, even when it is executable. With this patch, when
opening the executable, it verifies the X bit rather than the R
bit on the file, thus allowing the execution of dynamically
linked binaries that are executable but not readable.
This patch changes the prefetch API so that file systems must now
provide a set of block numbers, rather than a set of buffers. The
result is a leaner and more well-defined API; linear computation of
the range of blocks to prefetch; duplicates no longer interfering
with the prefetch process; guaranteed inclusion of the block needed
next into the prefetch range; and, limits and policy decisions better
established by libminixfs now actually being moved into libminixfs.
libminixfs: better support for read errors and EOF
- The lmfs_get_block*(3) API calls may now return an error. The idea
is to encourage a next generation of file system services to do a
better job at dealing with block read errors than the MFS-derived
implementations do. These existing file systems have been changed
to panic immediately upon getting a block read error, in order to
let unchecked errors cause corruption. Note that libbdev already
retries failing I/O operations a few times first.
- The libminixfs block device I/O module (bio.c) now deals properly
with end-of-file conditions on block devices. Since a device or
partition size may not be a multiple of the root file system's block
size, support for partial block retrival has been added, with a new
internal lmfs_get_partial_block(3) call. A new test program,
test85, tests the new handling of EOF conditions when reading,
writing, and memory-mapping a block device.
This patch changes the libminixfs API and implementation such that the
library is at all times aware of how many total and used blocks there
are in the file system. This removes the last upcall of libminixfs
into file systems (fs_blockstats). In the process, make this part of
the libminixfs API a little prettier and more robust. Change file
systems accordingly. Since this change only adds to MFS being unable
to deal with zones and blocks having different sizes, fail to mount
such file systems immediately rather than triggering an assert later.
This removes an implicit requirement for the way the libminixfs API is
to be used, namely that a block is to be marked as dirty only once its
contents have been fully updated, within a single get_block/put_block
window. The requirement may not be appropriate for all file systems.
With this change, the lmfs_get_block*(3) functions allow the caller to
specify that it only wants the block if it is in the cache or the
secondary VM cache. If the block is not found there, the functions
return NULL. Previously, the PREFETCH method would be used to this
end instead, which was both abuse in name and less efficient.
When VM asks a file system to provide a block to satisfy a page fault
on a file memory mapping, the file system previously had no way to
inform VM that the block is a hole, since there is no corresponding
block on the underlying device. To work around this, MFS and ext2
would actually allocate a block for the hole when asked by VM, which
not only defeats the point of holes in the first place, but also does
not work on read-only file systems. With this patch, a new libminixfs
call allows the file system to inform VM about holes. This issue does
raise the question as to whether the VM cache is using the right data
structures, since there are now two places where we have to fake a
device offset. This will have to be revisited in the future.
The patch changes file systems accordingly, and adds a test to test74.
This patch employs one solution to resolve two independent but related
issues. Both issues are the result of one fundamental aspect of the
way VM's memory mapping works: VM uses its cache to map in blocks for
memory-mapped file regions, and for blocks already in the VM cache, VM
does not go to the file system before mapping them in. To preserve
consistency between the FS and VM caches, VM relies on being informed
about all updates to file contents through the block cache. The two
issues are both the result of VM not being properly informed about
such updates:
1. Once a file system provides libminixfs with an inode association
(inode number + inode offset) for a disk block, this association
is not broken until a new inode association is provided for it.
If a block is freed and reallocated as a metadata (non-inode)
block, its old association is maintained, and may be supplied to
VM's secondary cache. Due to reuse of inodes, it is possible
that the same inode association becomes valid for an actual file
block again. In that case, when that new file is memory-mapped,
under certain circumstances, VM may end up using the metadata
block to satisfy a page fault on the file, due to the stale inode
association. The result is a corrupted memory mapping, with the
application seeing data other than the current file contents
mapped in at the file block.
2. When a hole is created in a file, the underlying block is freed
from the device, but VM is not informed of this update, and thus,
if VM's cache contains the block with its previous inode
association, this block will remain there. As a result, if an
application subsequently memory-maps the file, VM will map in the
old block at the position of the hole, rather than an all-zeroes
block. Thus, again, the result is a corrupted memory mapping.
This patch resolves both issues by making the file system inform the
minixfs library about blocks being freed, so that libminixfs can
break the inode association for that block, both in its own cache and
in the VM cache. Since libminixfs does not know whether VM has the
block in its cache or not, it makes a call to VM for each block being
freed. Thus, this change introduces more calls to VM, but it solves
the correctness issues at hand; optimizations may be introduced
later. On the upside, all freed blocks are now marked as clean,
which should result in fewer blocks being written back to the device,
and the blocks are removed from the caches entirely, which should
result in slightly better cache usage.
This patch is necessary but not sufficient to resolve the situation
with respect to memory mapping of file holes in general. Therefore,
this patch extends test 74 with a (rather particular but effective)
test for the first issue, but not yet with a test for the second one.
There is no reason to keep these tightly coupled data structures
separate. Moreover, there is no reason to have a union of file
descriptor and file pointer, since the second can be derived from
the first. The result are somewhat cleaner VFS internals.
If an asynchronous message is delivered during an ipc_receive(2) call,
but a failure occurred while copying out the status to the sending
process, then the receiving process would be left in an inconsistent
state, leading to a kernel crash shortly after.
For now, we fix this by altogether ignoring errors while copying out
the status field to the sending process. While this resolves the
kernel crash, it is hardly ideal, since it will likely cause the same
message to be delivered repeatedly. It would be better to disable
asynchronous communication from the sender process altogether, but this
solution requires more changes and thus more testing.
Previously, there was a tiny chance that tickdelay(3) would return
early or that it would fail to reinstate a previous alarm.
- sys_setalarm(2) now returns TMR_NEVER instead of 0 for the time
left if no previous alarm was set;
- sys_setalarm(2) now also returns the current time, to allow the
caller to determine whether it got an alarm notification for the
alarm it set or for a previous alarm that has just gone off;
- tickdelay(3) now makes use of these facilities.
The previous approach of including libraries through the parent
directory's Makefile.inc created linking issues, with libchardriver
not finding snprintf in certain cases. The new approach of including
libraries through the driver's only Makefile is the one used by all
other drivers.
This is the combination of two NetBSD patches committed by Christos
Zoulas, based on the findings and Bitrig patch by Martin Natano.
The NetBSD log messages read:
From Martin Natano @bitrig: Use execve(2) instead of system to
apply patches that require rcs command execution instead system(3)
to avoid malicious filenames in patches causing bad things to
happen. In the process, lose SCCS support. It is not like we are
shipping sccs commands for that to work.
And:
Use absolute paths for RCS commands (Martin Natano)
This test connects to a remote HTTP server to retrieve files, using various
chunk sizes and concurrency settings to exercise the network stack. The test
is only performed is USENETWORK=yes. This test requires the following URLs to
remain available: http://test82.minix3.org/test1.txt and
http://test82.minix3.org/test2.bin. The former contains a 'Hello world'
message followed by a newline, the latter all 16-bit values in increasing
order, using big-endian notation.
These new tests are largely based on the code from test 56 (UDS). Common code
is moved into a separate file common-socket.c. In some instances the tests
are too strict for TCP/UDP sockets, which may not always react instantly to
whatever happens on the other side (even locally). For these cases, the
ignore_* fields in struct socket_test_info indicate that there needs to be
an exception. There are also tests where it seems the functionality of inet
is either incorrect or incomplete with regard to the POSIX standard. In these
cases, the bug_* fields are used to document the issues while avoiding
failure of the test.
This patch introduces USENETWORK environment variable to determine whether to
use the network or not, instead of the unreliable ping test; set to 'yes' to
enable network usage.