With logical block provisioning support enabled, the provisioning map
(map_storep) keeps track of the provisioning status (mapped or unmapped)
for actual ramdisk storage range (fake_storep). The provisioning status
for out of fake_storep range with module parameter virtual_gb > 0 is
not tracked, and it should be assumed always mapped. It is reasonable,
because Unmap commands for such virtual range are always ignored.
Unfortunately, Get_LBA_status command for virtual range accesses out of
map_storep range. This fixes invalid access and makes it return correct
provisioning status.
Signed-off-by: Akinobu Mita <akinobu.mita@xxxxxxxxx>
Cc: "James E.J. Bottomley" <JBottomley@xxxxxxxxxxxxx>
Cc: Douglas Gilbert <dgilbert@xxxxxxxxxxxx>
Cc: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
Cc: linux-scsi@xxxxxxxxxxxxxxx
---
drivers/scsi/scsi_debug.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 1e25c1e..c519c9f 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -2014,6 +2014,7 @@ static sector_t map_index_to_lba(unsigned long index)
return lba;
}
+/* LBA from sdebug_store_sectors to sdebug_capacity is assumed mapped */
static unsigned int map_state(sector_t lba, unsigned int *num)
{
sector_t end;
@@ -2022,6 +2023,10 @@ static unsigned int map_state(sector_t lba, unsigned int *num)
unsigned long next;
index = lba_to_map_index(lba);
+ if (index >= map_size) {
+ *num = sdebug_capacity - lba;
+ return 1;
+ }
mapped = test_bit(index, map_storep);
if (mapped)
@@ -2029,7 +2034,11 @@ static unsigned int map_state(sector_t lba, unsigned int *num)
else
next = find_next_bit(map_storep, map_size, index);
- end = min_t(sector_t, sdebug_store_sectors, map_index_to_lba(next));
+ if (next >= map_size)
+ end = mapped ? sdebug_capacity : sdebug_store_sectors;
+ else
+ end = map_index_to_lba(next);
+
*num = end - lba;
return mapped;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
