[PATCH] Fix trivial typos in scsi_scan.c comment
Hi, Not much to say really... Signed-off-by: Mark Knibbs --- diff -upN linux-3.17/drivers/scsi/scsi_scan.c.orig linux-3.17/drivers/scsi/scsi_scan.c --- linux-3.17/drivers/scsi/scsi_scan.c.orig2014-10-05 20:23:04.0 +0100 +++ linux-3.17/drivers/scsi/scsi_scan.c 2014-10-09 12:32:53.0 +0100 @@ -1191,9 +1191,9 @@ static void scsi_sequential_lun_scan(str sparse_lun = 0; /* -* If less than SCSI_1_CSS, and no special lun scaning, stop +* If less than SCSI_1_CCS, and no special lun scanning, stop * scanning; this matches 2.4 behaviour, but could just be a bug -* (to continue scanning a SCSI_1_CSS device). +* (to continue scanning a SCSI_1_CCS device). * * This test is broken. We might not have any device on lun0 for * a sparselun device, and if that's the case then how would we -- 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] Fix off-by-one LUN check in scsi_scan_host_selected()
Hi, The Scsi_Host structure max_lun field is the maximum allowed LUN plus 1. So a LUN value is invalid if >= max_lun. Signed-off-by: Mark Knibbs --- diff -upN linux-3.17/drivers/scsi/scsi_scan.c.orig linux-3.17/drivers/scsi/scsi_scan.c --- linux-3.17/drivers/scsi/scsi_scan.c.orig2014-10-05 20:23:04.0 +0100 +++ linux-3.17/drivers/scsi/scsi_scan.c 2014-10-09 12:26:45.0 +0100 @@ -1704,7 +1704,7 @@ int scsi_scan_host_selected(struct Scsi_ if (((channel != SCAN_WILD_CARD) && (channel > shost->max_channel)) || ((id != SCAN_WILD_CARD) && (id >= shost->max_id)) || - ((lun != SCAN_WILD_CARD) && (lun > shost->max_lun))) + ((lun != SCAN_WILD_CARD) && (lun >= shost->max_lun))) return -EINVAL; mutex_lock(&shost->scan_mutex); -- 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] Fix comment typo in Scsi_Host struct definition
Hi, The comment for the max_channel, max_id and max_lun parameters refers to the first two, but actually means the last two. Signed-off-by: Mark Knibbs --- $ diff -upN linux-3.17/include/scsi/scsi_host.h.orig linux-3.17/include/scsi/scsi_host.h --- linux-3.17/include/scsi/scsi_host.h.orig2014-10-05 20:23:04.0 +0100 +++ linux-3.17/include/scsi/scsi_host.h 2014-10-09 12:18:47.0 +0100 @@ -606,7 +606,7 @@ struct Scsi_Host { /* * These three parameters can be used to allow for wide scsi, * and for host adapters that support multiple busses -* The first two should be set to 1 more than the actual max id +* The last two should be set to 1 more than the actual max id * or lun (e.g. 8 for SCSI parallel systems). */ unsigned int max_channel; -- 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
Off-by-one LUN validation in scsi_scan_host_selected()?
Hi, In drivers/scsi_scsi_scan.c, we have: int scsi_scan_host_selected(struct Scsi_Host *shost, unsigned int channel, unsigned int id, u64 lun, int rescan) ... if (((channel != SCAN_WILD_CARD) && (channel > shost->max_channel)) || ((id != SCAN_WILD_CARD) && (id >= shost->max_id)) || ((lun != SCAN_WILD_CARD) && (lun > shost->max_lun))) return -EINVAL; ... The max_lun field of the Scsi_Host structure (see include/scsi/scsi_host.h) seems to be defined as the actual maximum LUN plus 1: * These three parameters can be used to allow for wide scsi, * and for host adapters that support multiple busses * The first two should be set to 1 more than the actual max id * or lun (e.g. 8 for SCSI parallel systems). */ unsigned int max_channel; unsigned int max_id; u64 max_lun; [The comment has a typo; it refers to the max_id and max_lun fields as the first two, but they are the last two.] Shouldn't the LUN check in scsi_scan_host_selected() be (lun >= shost->max_lun)? Mark -- 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