The general trend is to remove it from all kernel interfaces and
this is a start. In case the calling lwp is desired, curlwp should
be used.
quick consensus on tech-kern
need to understand the locking around that field. Instead of setting
B_ERROR, set b_error instead. b_error is 'owned' by whoever completes
the I/O request.
Break one: because b_cylinder, and b_resid are one and the same.
The work the routine was commented as being its primary function,
end of patition adjustment, is wiped out, as at the end of
the routine b_cylinder is set, splat, doing a wipe out of the adjustment
to b_resid.
Break two: When doing the adjustment, a block count is created from a
byte count, a block calculation is done, then the results are compared to
the original byte count. i.e. apples to oranges, not blocks to blocks,
but blocks to bytes.
Break three: since if all the other drivers that used this routine
would have broken as vnd compress did, I must assume they always ignored
the results of this routine. So if end of patition adjustment is
really required then all these other drivers have been broken for a
long time.
(I did this because the system could panic otherwise. But this seemed to
be a side-effect of another mistake that was present in the code before it
was commited. So effectively this simplification should have happened
before.)
if not, fallback to VOP_READ and VOP_WRITE. This makes vnd work with files
on, e.g. tmpfs and smbfs; all file systems should behave as before.
OK'ed by silence in tech-kern@.
From various discussion about vndstrategy (see
http://mail-index.netbsd.org/tech-kern/2005/03/29/0034.htmlhttp://mail-index.netbsd.org/tech-kern/2005/03/23/0015.html)
it's not correct to tsleep() in a strategy routine, which may be called from
interrupt context.
Unfortunably this reopens PR/10731, PR/12189, PR/20296, PR/34293
As for what the correct fix it, this needs to be analysed deeper. I suspect
throttling the caller in vnd only hides the problem; the same caller writing
to some other device could exaust all buffers as well. If this driver doesn't
need to allocate buffer this won't cause a deadlock, but it's bad for
performances on systems with e.g. multiple drives. Also, others stacked
block device drivers may also have this issue.
spurious messages when doing "vnconfig -l", but it also means there won't
be a message when an actual device is created. Oh, well.
PR#33116 by Izumi Tsutsui.
- use vmspace rather than proc or lwp where appropriate.
the latter is more natural to specify an address space.
(and less likely to be abused for random purposes.)
- fix a swdmover race.
for "strange" filesystems like nfs. PR/32671 from Simon Burge.
although i'm not really happy with this "fix", i think that the code will
be replaced with direct i/o anyway, sooner or later...
- rather than embedding bufq_state in driver softc,
have a pointer to the former.
- move bufq related functions from kern/subr_disk.c to kern/subr_bufq.c.
- rename method to strategy for consistency.
- move some definitions which don't need to be exposed to the rest of kernel
from sys/bufq.h to sys/bufq_impl.h.
(is it better to move it to kern/ or somewhere?)
- fix some obvious breakage in dev/qbus/ts.c. (not tested)
pooka