* [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation
@ 2019-07-02 19:16 ` Roman Bolshakov
0 siblings, 0 replies; 11+ messages in thread
From: Roman Bolshakov @ 2019-07-02 19:16 UTC (permalink / raw)
To: target-devel, linux-scsi
Cc: Roman Bolshakov, Martin K. Petersen, stable, Bart Van Assche
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
^ permalink raw reply related [flat|nested] 11+ messages in thread* [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation
@ 2019-07-02 19:16 ` Roman Bolshakov
0 siblings, 0 replies; 11+ messages in thread
From: Roman Bolshakov @ 2019-07-02 19:16 UTC (permalink / raw)
To: target-devel, linux-scsi
Cc: Roman Bolshakov, Martin K. Petersen, stable, Bart Van Assche
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
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation
2019-07-02 19:16 ` Roman Bolshakov
(?)
@ 2019-07-02 20:37 ` Martin K. Petersen
-1 siblings, 0 replies; 11+ messages in thread
From: Martin K. Petersen @ 2019-07-02 20:37 UTC (permalink / raw)
To: Roman Bolshakov
Cc: target-devel, linux-scsi, Martin K. Petersen, stable,
Bart Van Assche
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation
@ 2019-07-02 20:37 ` Martin K. Petersen
0 siblings, 0 replies; 11+ messages in thread
From: Martin K. Petersen @ 2019-07-02 20:37 UTC (permalink / raw)
To: Roman Bolshakov
Cc: target-devel, linux-scsi, Martin K. Petersen, stable,
Bart Van Assche
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation
@ 2019-07-02 20:37 ` Martin K. Petersen
0 siblings, 0 replies; 11+ messages in thread
From: Martin K. Petersen @ 2019-07-02 20:37 UTC (permalink / raw)
To: Roman Bolshakov
Cc: target-devel, linux-scsi, Martin K. Petersen, stable,
Bart Van Assche
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation
2019-07-02 19:16 ` Roman Bolshakov
@ 2019-07-03 3:40 ` Michael Christie
-1 siblings, 0 replies; 11+ messages in thread
From: Michael Christie @ 2019-07-03 3:40 UTC (permalink / raw)
To: Roman Bolshakov, target-devel, linux-scsi
Cc: Martin K. Petersen, stable, Bart Van Assche
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?
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation
@ 2019-07-03 3:40 ` Michael Christie
0 siblings, 0 replies; 11+ messages in thread
From: Michael Christie @ 2019-07-03 3:40 UTC (permalink / raw)
To: Roman Bolshakov, target-devel, linux-scsi
Cc: Martin K. Petersen, stable, Bart Van Assche
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?
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation
2019-07-03 3:40 ` Michael Christie
(?)
@ 2019-07-03 13:24 ` Roman Bolshakov
-1 siblings, 0 replies; 11+ messages in thread
From: Roman Bolshakov @ 2019-07-03 13:24 UTC (permalink / raw)
To: Michael Christie
Cc: target-devel, linux-scsi, Martin K. Petersen, stable,
Bart Van Assche
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation
@ 2019-07-03 13:24 ` Roman Bolshakov
0 siblings, 0 replies; 11+ messages in thread
From: Roman Bolshakov @ 2019-07-03 13:24 UTC (permalink / raw)
To: Michael Christie
Cc: target-devel, linux-scsi, Martin K. Petersen, stable,
Bart Van Assche
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RESEND PATCH] scsi: target/iblock: Fix overrun in WRITE SAME emulation
@ 2019-07-03 13:24 ` Roman Bolshakov
0 siblings, 0 replies; 11+ messages in thread
From: Roman Bolshakov @ 2019-07-03 13:24 UTC (permalink / raw)
To: Michael Christie
Cc: target-devel, linux-scsi, Martin K. Petersen, stable,
Bart Van Assche
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
^ permalink raw reply [flat|nested] 11+ messages in thread