SG_DXFER_TO_FROM_DEV is weird everywhere, but skd manages to get it
even stranger than usual: copying to/from userland happens in
skd_sg_io_copy_buffer(), which is called twice - once before the actual
talking to device and once after. The first call either does nothing or
copies from userland, the second one either does nothing or copies to
userland. So far, so good, but the logics in that sucker deciding whether
to bugger off or not is wrong:
if (dxfer_dir != sksgio->sg.dxfer_direction) {
if (dxfer_dir != SG_DXFER_TO_DEV ||
sksgio->sg.dxfer_direction != SG_DXFER_TO_FROM_DEV)
return 0;
}
The first call is with dxfer_dir equal to SG_DXFER_TO_DEV, the second -
SG_DXFER_FROM_DEV. So we get
SG_DXFER_NONE: nothing nothing
SG_DXFER_FROM_DEV: nothing out
SG_DXFER_TO_DEV: in nothing
SG_DXFER_TO_FROM_DEV: in nothing
I've no idea if anything is still using SG_DXFER_TO_FROM_DEV, but this
behaviour AFAICS doesn't match that of write() on /dev/sg* (both
in and out are done) or normal SG_IO (either both in and out, in case if it
hits bio_map_user_iov(), or only out if it hits bio_copy_user_iov()). In
all cases the out part is done. Here it is skipped.
Not sure who (if anybody) maintains it these days, but that behaviour looks
wrong...
--
To unsubscribe from this list: send the line "unsubscribe linux-block" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
