use the index ops at a offset of the page size as well, controlled by
an MIPS64_SB1 check. The SB1 D-cache way size is physically indexed
and twice as big as the page size (4k), so we weren't flushing all the
addresses we needed too.
XXX: This is kinda gross; will be cleaned up and made more generic soon.
There are still other SB1-specific issues to be cleaned up too...
noticed by and fix from Miod Vallat <miod@openbsd.org>.
Miod's OpenBSD log message:
> Don't uvm_useracc the user sigcontext in sys_sigreturn and then access
> the user addresses directly from the kernel. copyin is faster and can
> correctly deal properly with mappings that uvm_useracc thinks are
> correct but will fault anyway (to figure out how to generate such
> mappings is left as en excercise for the reader).
>
> Blatantly stolen from art@'s similar fix to sparc.
with:
Case #1 -- adjust offset: The slot offset in the aref can be
decremented to cover the required size addition.
Case #2 -- move pages and adjust offset: The slot offset is not large
enough, but the amap contains enough inactive space *after* the mapped
pages to make up the difference, so active slots are slid to the "end"
of the amap, and the slot offset is, again, adjusted to cover the
required size addition. This optimizes for hitting case #1 again on
the next small extension.
Case #3 -- reallocate, move pages, and adjust offset: There is not
enough inactive space in the amap, so the arrays are reallocated, and
the active pages are copied again to the "end" of the amap, and the
slot offset is adjusted to cover the required size. This also
optimizes for hitting case #1 on the next backwards extension.
This provides the missing piece in the "forward extension of
vm_map_entries" logic, so the merge failure counters have been
removed.
Not many applications will make any use of this at this time (except
for jvms and perhaps gcc3), but a "top-down" memory allocator will use
it extensively.
This bug appears as "incorrect Mod Counters" in 'raidctl -s'. The
reason it was seen only in 'raidctl -s' is because of the conditions
needed to trigger the bug:
a) a raid set is configured
b) no partitions on that set are mounted or are otherwise in-use
c) a component is failed, and subsequently rebuilt to a hot spare
d) the machine is rebooted while something (e.g. 'raidctl -s') has
the device open (and, therefore, rf_markalldirty() has been called)
but before the final rf_update_component_labels() is done.
Needless to say, the window for this happening is *very* small, and it
was only because I was testing some obscure stuff that I even noticed it.
failing a component that has been spared, or "double-failing"
an already failed component. XXX This isn't the right place to fix
this, but better here than no-where (and I'm hoping to move it sometime
soon).
ad