shuffle code in xbd_handler() response loop so that req_bp is never
touched for non I/O responses; unknown commands are now just skipped, also
without touching neither xbdreq, nor req_bp
add some KASSERTS() for xbdreq->req_nr_segments and xbdreq->req_bp,
and reset req_bp after it's processed to ensure the buf can never
be processed twice
intended to simplify debugging in cases like PR port-xen/53506
EINVAL straight away
the condition doesn't seem to be actually hit for normal boots and
tools like fsck, which is good thing since it allocated memory
separately for each such I/O
interrupt handling in xbd_handler() - need to protect it with splbio()
fixes PR port-xen/53506 by Emmanuel Dreyfus, and likely also port-xen/53074
by Brad Spencer
and that any data supposedly copied out is valid before use.
prompted by maxv@, I have checked every usage of m_copydata() and made
the following corrections
hci_event.c:
hci_event_command_compl()
check that the packet does contain enough data for there to
be a status code before noting possible failures.
hci_event_num_compl_pkts()
check that the packet does contain data to cover the
stated number of handle/num pairs
l2cap_signal.c:
l2cap_recv_signal()
just ignore packets with not enough data rather than
trying to reject them (may not have cmd.ident)
l2cap_recv_command_rej()
check we have a valid reason and/or data before use
userland, all it contains is a few prototypes for kernel functions.
So, don't install asan.h in /usr/include/sys (if it ever gains
anything which would be useful, then this can be changed).
Note: I have simply removed /usr/includ/esys/asan.hit from the sets
list, rather than marking it obsolete - it has not been there for
very long, If you get build problems (sets list errors) from an
update build because you managed to install it during the last few
hours, just remove asan.h from /usr/include/sys
from Siddharth Muralee's initial work. This feature can detect several
kinds of memory bugs, and it's an excellent feature.
It can be enabled by uncommenting these three lines in GENERIC:
#makeoptions KASAN=1 # Kernel Address Sanitizer
#options KASAN
#no options SVS
The kernel is compiled without SVS, without DMAP and without PCPU area.
A shadow area is created at boot time, and it can cover the upper 128TB
of the address space. This area is populated gradually as we allocate
memory. With this design the memory consumption is kept at its lowest
level.
The compiler calls the __asan_* functions each time a memory access is
done. We verify whether this access is legal by looking at the shadow
area.
We declare our own special memcpy/memset/etc functions, because the
compiler's builtins don't add the __asan_* instrumentation.
Initially all the mappings are marked as valid. During dynamic
allocations, we add a redzone, which we mark as invalid. Any access on
it will trigger a kASan error message. Additionally, the compiler adds
a redzone on global variables, and we mark these redzones as invalid too.
The illegal-access detection works with a 1-byte granularity.
For now, we cover three areas:
- global variables
- kmem_alloc-ated areas
- malloc-ated areas
More will come, but that's a good start.
KMEM_REDZONE is not very efficient and cannot detect read overflows. KASAN
can, and will be used instead.
KMEM_POISON is enabled along with KMEM_GUARD, but it is redundant, since
the latter can detect read UAFs contrary to the former. In fact maybe
KMEM_GUARD should be retired too, because there are many cases where it
doesn't apply.
Simplifies the code.
* Don't use IP_PKTINFO on NetBSD-7 as it's incomplete.
* Workaround RTM_NEWADDR sending the wrong broadcast address
on NetBSD-7.
* Silence diagnostics if an address vanishes when reading
it's flags on all BSD's.
* Misc compiler warnings fixed.
Import a whole set of tree evaluation enhancements from FreeBSD.
With these, before forking, the shell predicts (often) when all it will
have to do after forking (in the parent) is wait for the child and then
exit with the status from the child, and in such a case simply does not
fork, but rather allows the child to take over the parent's role.
This turns out to handle the particular test case from PR bin/48875 in
such a way that it works as hoped, rather than as it did (the delay there
was caused by an extra copy of the shell hanging around waiting for the
background child to complete ... and keeping the command substitution
stdout open, so the "real" parent had to wait in case more output appeared).
As part of doing this, redirection processing for compound commands gets
moved out of evalsubshell() and into a new evalredir(), which allows us
to properly handle errors occurring while performing those redirects,
and not mishandle (as in simply forget) fd's which had been moved out
of the way temporarily.
evaltree() has its degree of recursion reduced by making it loop to
handle the subsequent operation: that is instead of (for any binop
like ';' '&&' (etc)) where it used to
evaltree(node->left);
evaltree(node->right);
return;
it now does (kind of)
next = node;
while ((node = next) != NULL) {
next = NULL;
if (node is a binary op) {
evaltree(node->left);
if appropriate /* if && test for success, etc */
next = node->right;
continue;
}
/* similar for loops, etc */
}
which can be a good saving, as while the left side (now) tends to be
(usually) a simple (or simpleish) command, the right side can be many
commands (in a command sequence like a; b; c; d; ... the node at the
top of the tree will now have "a" as its left node, and the tree for
b; c; d; ... as its right node - until now everything was evaluated
recursively so it made no difference, and the tree was constructed
the other way).
if/while/... statements are done similarly, recurse to evaluate the
condition, then if the (or one of the) body parts is to be evaluated,
set next to that, and loop (previously it recursed).
There is more to do in this area (particularly in the way that case
statements are processed - we can avoid recursion there as well) but
that can wait for another day.
While doing all of this we keep much better track of when the shell is
just going to exit once the current tree is evaluated (with a new
predicate at_eof() to tell us that we have, for sure, reached the end
of the input stream, that is, this shell will, for certain, not be reading
more command input) and use that info to avoid unneeded forks. For that
we also need another new predicate (have_traps()) to determine of there
are any caught traps which might occur - if there are, we need to remain
to (potentially) handle them, so these optimisations will not occur (to
make the issue in PR 48875 appear again, run the same code, but with a
trap set to execute some code when a signal (or EXIT) occurs - note that
the trap must be set in the appropriate level of sub-shell to have this
effect, any caught traps are cleared in a subshell whenever one is created).
There is still work to be done to handle traps properly, whatever
weirdness they do (some of which is related to some of this.)
These changes do not need man page updates, but 48875 does - an update
to sh.1 will be forthcoming once it is decided what it should say...
Once again, all the heavy lifting for this set of changes comes directly
(with thanks) from the FreeBSD shell.
XXX pullup-8 (but not very soon)
While this change does mean that each open mqd_t counts against the
limit, it also means that p_mqueue_cnt will never wrap below 0.
Discovered by the Rust nix crate test suite. It opens the same mq twice
(once for writes, once for reads), and then proceeds to close each of
them, which resulted in p_mqueue_cnt wrapping to (u_int)-1, preventing
the process from opening any more mqueues, and all subsequent
mq(3)-related tests to fail.
Revert the changes that were made 19 May 2016 (principally eval.c 1.125)
and the bug fixes in subsequent days (eval.c 1.126 and 1.127) and also
update some newer code that was added more recently which acted in
accordance with those changes (make that code be as it would have been
if the changes now being reverted had never been made).
While the changes made did solve the problem, in a sense, they were
never correct (see the PR for some discussion) and it had always been
intended that they be reverted. However, in practical sh code, no
issues were reported - until just recently - so nothing was done,
until now...
After this commit, the validate_fn_redirects test case of the sh ATF
test t_redir will fail. In particular, the subtest of that test
case which is described in the source (of the test) as:
This one is the real test for PR bin/48875
will fail.
Alternative changes, not to "fix" the problem in the PR, but to
often avoid it will be coming very soon - after which that ATF
test will succeed again.
XXX pullup-8
jdolecek