- return EOPNOTSUPP if min_addr isn't less than max_addr
- fix the subset check to ensure that all the ranges in the parent tag are
within the {min,max}_addr range. If so we can just continue to use the
parent tag.
- when building the new ranges read the parent tag range rather than un-
initialised memory.
- remove the max_addr != 0xffffffff check - the overflow should be handled
by the unsigned arithmetic for arm32.
- add a KASSERT
- add comments
In suff.c r1.144 from yesterday, in the line "cp += nested_p - cp", I
accidentally removed the "- 1". Since these "- 1" lines lead to slow
execution, each branch now increments the pointer separately by the
actually needed amount.
Fixing this bug posed way more new questions than it answered, and it
revealed an inconsistency in the parser about how characters are to be
escaped, and missing details in the documentation of Var_Parse, as well
as a parse error that unexpectedly doesn't stop make from continuing.
This makes the output a bit more reproducible. There are still the file
descriptors, which may differ between different runs, but at least the
nextbuf function is printed using a symbolic name instead of a meaningless address.
Besides loadedfile_nextbuf, the only other function is ForIterate.
The race is caused by the following.
CPU#A processes workqueue, CPU#B processes admin interrupt.
(0) one of CPUs already calls ixgbe_schedule_admin_tasklet()
such as ixgbe_handle_timer()
(1) CPU#A: read adapter->task_requests
(2) CPU#B: set adapter->task_requests
(3) CPU#B: read(and try to set) adapter->admin_pending
but adapter->admin_pending is set, so does not
call workqueue_enqueue()
(4) CPU#A: clear adapter->admin_pending
that is, the tasks set by (2) is not processed as missfire workqueue by (3).
- most builds are working
- arm64, amd64, sparc, evbmips64-eb, and armv7hf-el are known to be
stable and work
- mips64-el needs new binutils, in testing
- vax, sh3*, riscv64 and mipse[lb] builds are broken in various ways
skrll