[RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation

[RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation

[Roman Bolshakov]

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);
-- 
2.22.0

Re: [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation

[Martin K. Petersen]

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!

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation

[Michael Christie]

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?

Re: [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation

[Roman Bolshakov]

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