On Thu, 09 Jul 2009 02:19:22 +0200 Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote: > FUJITA Tomonori wrote: > > I overlooked SG_DXFER_TO_FROM_DEV support when I converted sg to use > > the block layer mapping API (2.6.28). > > > > Douglas Gilbert explained SG_DXFER_TO_FROM_DEV: > > > > http://www.spinics.net/lists/linux-scsi/msg37135.html > > > > = > > The semantics of SG_DXFER_TO_FROM_DEV were: > > - copy user space buffer to kernel (LLD) buffer > > - do SCSI command which is assumed to be of the DATA_IN > > (data from device) variety. This would overwrite > > some or all of the kernel buffer > > - copy kernel (LLD) buffer back to the user space. > > > > The idea was to detect short reads by filling the original > > user space buffer with some marker bytes ("0xec" it would > > seem in this report). The "resid" value is a better way > > of detecting short reads but that was only added this century > > and requires co-operation from the LLD. > > = > > > > This patch changes the block layer mapping API to support this > > semantics. This simply adds another field to struct rq_map_data and > > enables __bio_copy_iov() to copy data from user space even with READ > > requests. > > > > It's better to add the flags field and kills null_mapped and the new > > from_user fields in struct rq_map_data but that approach makes it > > difficult to send this patch to stable trees because st and osst > > drivers use struct rq_map_data (they were converted to use the block > > layer in 2.6.29 and 2.6.30). Well, I should clean up the block layer > > mapping API. > > > > zhou sf reported this regiression and tested this patch: > > > > http://www.spinics.net/lists/linux-scsi/msg37128.html > > http://www.spinics.net/lists/linux-scsi/msg37168.html > > Wrote my own little test program and it gave the wrong > result (as reported by zhou sf) in lk 2.6.30 . When > this patch was applied, the expected result (i.e. a > response with user supplied fill characters) was observed. > > Here is an INQUIRY response set up for a length of > 128 bytes with an 0xec fill character: > > $ ./sg_dxfer_to_from > resid indicates that 96 bytes returned in response > 00 00 00 05 02 5b 00 10 0a 4c 69 6e 75 78 20 20 20 > 10 73 63 73 69 5f 64 65 62 75 67 20 20 20 20 20 20 > 20 30 30 30 34 00 00 00 00 00 00 00 00 00 00 00 00 > 30 00 00 00 00 00 00 00 00 00 00 00 77 03 14 03 3d > 40 0c 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 60 ec ec ec ec ec ec ec ec ec ec ec ec ec ec ec ec > 70 ec ec ec ec ec ec ec ec ec ec ec ec ec ec ec ec > > > Signed-off-by: Douglas Gilbert <dgilbert@xxxxxxxxxxxx> Thanks for testing! Jens, please apply this patch. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
