Re: [PATCH] scsi: Avoid crashing if device uses DIX but adapter does not support it

[Ewan Milne]

On Wed, 2015-01-14 at 20:18 -0500, Martin K. Petersen wrote:
> > "Ewan" == Ewan D Milne  writes:
> 
> Ewan> This can happen if a multipathed device uses DIX and another path
> Ewan> is added via an adapter that does not support it.  Multipath
> Ewan> should not allow this path to be added,
> 
> No it shouldn't :)
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 6d5c0b8..4f14f4a 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1143,7 +1143,17 @@ int scsi_init_io(struct scsi_cmnd *cmd)
>   struct scsi_data_buffer *prot_sdb = cmd->prot_sdb;
>   int ivecs, count;
>  
> - BUG_ON(prot_sdb == NULL);
> + if (prot_sdb == NULL) {
> + /*
> +  * This can happen if someone (e.g. multipath)
> +  * queues a command to a device on an adapter
> +  * that does not support T10 PI.
> 
> s/T10 PI/DIX/

Good point.  I'll submit a v2 to change the comment.

> 
> +  */
> + WARN_ON_ONCE(1);
> + error = BLKPREP_KILL;
> + goto err_exit;
> + }
> +
>   ivecs = blk_rq_count_integrity_sg(rq->q, rq->bio);
>  
>   if (scsi_alloc_sgtable(prot_sdb, ivecs, is_mq)) {
> 
> Failing more gracefully is OK with me.
> 
> Acked-by: Martin K. Petersen 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: Avoid crashing if device uses DIX but adapter does not support it

[Martin K. Petersen]

> "Ewan" == Ewan D Milne  writes:

Ewan> This can happen if a multipathed device uses DIX and another path
Ewan> is added via an adapter that does not support it.  Multipath
Ewan> should not allow this path to be added,

No it shouldn't :)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 6d5c0b8..4f14f4a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1143,7 +1143,17 @@ int scsi_init_io(struct scsi_cmnd *cmd)
struct scsi_data_buffer *prot_sdb = cmd->prot_sdb;
int ivecs, count;
 
-   BUG_ON(prot_sdb == NULL);
+   if (prot_sdb == NULL) {
+   /*
+* This can happen if someone (e.g. multipath)
+* queues a command to a device on an adapter
+* that does not support T10 PI.

s/T10 PI/DIX/

+*/
+   WARN_ON_ONCE(1);
+   error = BLKPREP_KILL;
+   goto err_exit;
+   }
+
ivecs = blk_rq_count_integrity_sg(rq->q, rq->bio);
 
if (scsi_alloc_sgtable(prot_sdb, ivecs, is_mq)) {

Failing more gracefully is OK with me.

Acked-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] scsi: Avoid crashing if device uses DIX but adapter does not support it

[Ewan D. Milne]

From: "Ewan D. Milne" 

This can happen if a multipathed device uses DIX and another path is
added via an adapter that does not support it.  Multipath should not
allow this path to be added, but we should not depend upon that to avoid
crashing.

Signed-off-by: Ewan D. Milne 
---
 drivers/scsi/scsi_lib.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 6d5c0b8..4f14f4a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1143,7 +1143,17 @@ int scsi_init_io(struct scsi_cmnd *cmd)
struct scsi_data_buffer *prot_sdb = cmd->prot_sdb;
int ivecs, count;
 
-   BUG_ON(prot_sdb == NULL);
+   if (prot_sdb == NULL) {
+   /*
+* This can happen if someone (e.g. multipath)
+* queues a command to a device on an adapter
+* that does not support T10 PI.
+*/
+   WARN_ON_ONCE(1);
+   error = BLKPREP_KILL;
+   goto err_exit;
+   }
+
ivecs = blk_rq_count_integrity_sg(rq->q, rq->bio);
 
if (scsi_alloc_sgtable(prot_sdb, ivecs, is_mq)) {
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html