with arraysize instead of arraysize-1. Previously there was one
inconsistency in the code. This might fix a crash reported by apb.
Also, g/c outdated comment.
PR kern/16942 panic with softdep and quotas
PR kern/19565 panic: softdep_write_inodeblock: indirect pointer #1 mismatch
PR kern/26274 softdep panic: allocdirect_merge: ...
PR kern/26374 Long delay before non-root users can write to softdep partitions
PR kern/28621 1.6.x "vp != NULL" panic in ffs_softdep.c:4653 while unmounting a softdep (+quota) filesystem
PR kern/29513 FFS+Softdep panic with unfsck-able file-corruption
PR kern/31544 The ffs softdep code appears to fail to write dirty bits to disk
PR kern/31981 stopping scsi disk can cause panic (softdep)
PR kern/32116 kernel panic in softdep (assertion failure)
PR kern/32532 softdep_trackbufs deadlock
PR kern/37191 softdep: locking against myself
PR kern/40474 Kernel panic after remounting raid root with softdep
Retire softdep, pass 2. As discussed and later formally announced on the
mailing lists.
by setting RUMP_BLKFAIL to control the frequency and optionally
RUMP_BLKFAIL_SEED, which seeds the "random" number generator. Feel
free to extend the code if you want something "a little more" for
your purposes.
relative time. This prevents drifting. Also, keep track of time
within userspace, so we do not have to make a syscall to get the
clock value. This is approximately 7 times cheaper, but on the
negative side is limited to the clock interrupt frequency.
except keep my feet warm by consuming an insane amount of cpu
cycles -- in rump our current "cpu" context is never interrupted
& we have MULTIPROCESSOR.
(itch i'm scratching: it made the networking stack 10-20% slower.
this is one of the places where fast code actually matters)
* do not panic if VOP_STRATEGY fails. it's someone else's problem
* return the actual number of pages we provided, not just the ones
which contain data
* sprinkle some debug prints
(it might be a better to chain a few clusters into the iov
instead of just one since we are making the syscall anyway)
* don't overwrite the useful error value
io descriptors, just allocate an array statically and be happy.
Fixes a problem found by Arnaud Ysmal where a descriptor would be
allocated using kmem_alloc(9) and free'd using free(3).
return EINVAL and result in not protecting what they are supposed
to protect. This results in the counter value getting corrupted
and asserts firing.
Problem reported by Arnaud Ysmal.
While debugging this, take the opportunity to remove explicit
pthread_t comparisons and put everything under pthread_equal().
