| Message ID | 20190702191636.26481-1-r.bolshakov@yadro.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [RESEND] scsi: target/iblock: Fix overrun in WRITE SAME emulation | expand |
Roman, > WRITE SAME corrupts data on the block device behind iblock if the > command is emulated. The emulation code issues (M - 1) * N times more > bios than requested, where M is the number of 512 blocks per real > block size and N is the NUMBER OF LOGICAL BLOCKS specified in WRITE > SAME command. So, for a device with 4k blocks, 7 * N more LBAs gets > written after the requested range. > > The issue happens because the number of 512 byte sectors to be written > is decreased one by one while the real bios are typically from 1 to 8 > 512 byte sectors per bio. Applied to 5.2/scsi-fixes, thanks!
On 07/03/2019 04:16 AM, Roman Bolshakov wrote: > WRITE SAME corrupts data on the block device behind iblock if the > command is emulated. The emulation code issues (M - 1) * N times more > bios than requested, where M is the number of 512 blocks per real block > size and N is the NUMBER OF LOGICAL BLOCKS specified in WRITE SAME > command. So, for a device with 4k blocks, 7 * N more LBAs gets written > after the requested range. > > The issue happens because the number of 512 byte sectors to be written > is decreased one by one while the real bios are typically from 1 to 8 > 512 byte sectors per bio. > > Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") > Cc: <stable@vger.kernel.org> > Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> > Reviewed-by: Bart Van Assche <bvanassche@acm.org> > --- > drivers/target/target_core_iblock.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c > index f4a075303e9a..6949ea8bc387 100644 > --- a/drivers/target/target_core_iblock.c > +++ b/drivers/target/target_core_iblock.c > @@ -502,7 +502,7 @@ iblock_execute_write_same(struct se_cmd *cmd) > > /* Always in 512 byte units for Linux/Block */ > block_lba += sg->length >> SECTOR_SHIFT; > - sectors -= 1; > + sectors -= sg->length >> SECTOR_SHIFT; > } > > iblock_submit_bios(&list); > Roman, The patch looks ok to me. Just one question. How did you hit this? Did you by any chance export this disk to a ESX initiator and was it doing WRITE SAME to zero out data. But, did the device being used by iblock not support the zero out command (was /sys/block/XYZ/queue/write_zeroes_max_bytes == 0)? Or, did you just send a WRITE SAME command manually using some tools like sg utils and it had a non zero'd buffer to write out? Or, was it some other use case?
On Wed, Jul 03, 2019 at 12:40:29PM +0900, Michael Christie wrote: > On 07/03/2019 04:16 AM, Roman Bolshakov wrote: > > WRITE SAME corrupts data on the block device behind iblock if the > > command is emulated. The emulation code issues (M - 1) * N times more > > bios than requested, where M is the number of 512 blocks per real block > > size and N is the NUMBER OF LOGICAL BLOCKS specified in WRITE SAME > > command. So, for a device with 4k blocks, 7 * N more LBAs gets written > > after the requested range. > > > > The issue happens because the number of 512 byte sectors to be written > > is decreased one by one while the real bios are typically from 1 to 8 > > 512 byte sectors per bio. > > > Roman, > > The patch looks ok to me. Just one question. How did you hit this? > Hi Michael, The initiator was CentOS 7.x with distro kernel (3.10.0-x). There were two cases: * Initiatalization [1] and online resize of ext4 filesystem [2] use WRITE SAME [3] for zeroing. TCM doesn't support RSOC, so the initiator defaults to using WRITE SAME (10). The filesystem showed errors after online resize; * a WRITE SAME command for the last LBA was stuck in multipath. TCM always returned LOGICAL UNIT NOT SUPPORTED for the command. The resason of the response is because some bios were sent beyond the sector limit. WRITE SAME with NUMBER OF LOGICAL BLOCKS == 1 was failing for the last 7 LBAs. > Did you by any chance export this disk to a ESX initiator and was it > doing WRITE SAME to zero out data. But, did the device being used by > iblock not support the zero out command (was > /sys/block/XYZ/queue/write_zeroes_max_bytes == 0)? > It did not support zero out and write same, both write_zeroes_max_bytes/write_same_max_bytes == 0 > Or, did you just send a WRITE SAME command manually using some tools > like sg utils and it had a non zero'd buffer to write out? > Yes, I triaged the issues above with sg_write_same/sg_dd and non-zero buffer. 1. https://patchwork.ozlabs.org/patch/66590/ 2. https://lists.openwall.net/linux-ext4/2012/01/04/14 3. https://www.spinics.net/lists/linux-scsi/msg57783.html Best regards, Roman
diff --git a/drivers/target/target_core_iblock.c b/drivers/target/target_core_iblock.c index f4a075303e9a..6949ea8bc387 100644 --- a/drivers/target/target_core_iblock.c +++ b/drivers/target/target_core_iblock.c @@ -502,7 +502,7 @@ iblock_execute_write_same(struct se_cmd *cmd) /* Always in 512 byte units for Linux/Block */ block_lba += sg->length >> SECTOR_SHIFT; - sectors -= 1; + sectors -= sg->length >> SECTOR_SHIFT; } iblock_submit_bios(&list);
WRITE SAME corrupts data on the block device behind iblock if the command is emulated. The emulation code issues (M - 1) * N times more bios than requested, where M is the number of 512 blocks per real block size and N is the NUMBER OF LOGICAL BLOCKS specified in WRITE SAME command. So, for a device with 4k blocks, 7 * N more LBAs gets written after the requested range. The issue happens because the number of 512 byte sectors to be written is decreased one by one while the real bios are typically from 1 to 8 512 byte sectors per bio. Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") Cc: <stable@vger.kernel.org> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> --- drivers/target/target_core_iblock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)