Test if VOP_BMAP actually works before using bmap/strategy.
When you create an image with
dd if=/dev/zero of=./netbsd.img bs=1m count=1 seek=1000
then the current check actually determines the "file system"
in the image supports VOP_BMAP and VOP_STRATEGY, but VOP_BMAP can't
translate any logical block numbers which results in EIO failures.
When you try to access the image in a Xen DomU you see all disk operations
failing. Therefore test if VOP_BMAP actually works and fall back to
VOP_READ/VOP_WRITE if it doesn't.
This makes a Xen DomU installation working. When you boot your fresh
installed Xen DomU with a valid disklabel and file system in the image,
VOP_BMAP actually works and is used.
This allows you to create an image with dd as above on the Dom0 and
run a DomU installation or to quickly create another virtual disk for
an existing DomU without having to create a disklabel and file system
by hand.
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...
