* [PATCH 1/8] tcm_loop: Hook into SAS transport class
2015-06-18 9:43 [PATCH 0/8] tcm_loop updates Hannes Reinecke
@ 2015-06-18 9:43 ` Hannes Reinecke
2015-06-18 9:43 ` [PATCH 2/8] tcm_loop: Add SAS transport topology Hannes Reinecke
` (7 subsequent siblings)
8 siblings, 0 replies; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-18 9:43 UTC (permalink / raw)
To: Nic Bellinger
Cc: target-devel, linux-scsi, Christoph Hellwig, Ewan Milne,
Hannes Reinecke
If tcm_loop emulates a SAS HBA it should hook into the SAS
transport class, too.
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
drivers/target/loopback/tcm_loop.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c
index a556bde..45ae3e4 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -31,6 +31,7 @@
#include <scsi/scsi_host.h>
#include <scsi/scsi_device.h>
#include <scsi/scsi_cmnd.h>
+#include <scsi/scsi_transport_sas.h>
#include <target/target_core_base.h>
#include <target/target_core_fabric.h>
@@ -42,7 +43,7 @@
static struct workqueue_struct *tcm_loop_workqueue;
static struct kmem_cache *tcm_loop_cmd_cache;
-
+static struct scsi_transport_template *tcm_loop_sas_transport_template;
static int tcm_loop_hba_no_cnt;
static int tcm_loop_queue_status(struct se_cmd *se_cmd);
@@ -360,6 +361,9 @@ static int tcm_loop_slave_alloc(struct scsi_device *sd)
return 0;
}
+struct sas_function_template tcm_loop_sas_transport_functions = {
+};
+
static struct scsi_host_template tcm_loop_driver_template = {
.show_info = tcm_loop_show_info,
.proc_name = "tcm_loopback",
@@ -408,6 +412,8 @@ static int tcm_loop_driver_probe(struct device *dev)
sh->max_lun = 0;
sh->max_channel = 0;
sh->max_cmd_len = SCSI_MAX_VARLEN_CDB_SIZE;
+ if (tl_hba->tl_proto_id == SCSI_PROTOCOL_SAS)
+ sh->transportt = tcm_loop_sas_transport_template;
host_prot = SHOST_DIF_TYPE1_PROTECTION | SHOST_DIF_TYPE2_PROTECTION |
SHOST_DIF_TYPE3_PROTECTION | SHOST_DIX_TYPE1_PROTECTION |
@@ -1290,8 +1296,15 @@ static int __init tcm_loop_fabric_init(void)
if (ret)
goto out_release_core_bus;
+ tcm_loop_sas_transport_template =
+ sas_attach_transport(&tcm_loop_sas_transport_functions);
+ if (!tcm_loop_sas_transport_template)
+ goto out_unregister_template;
+
return 0;
+out_unregister_template:
+ target_unregister_template(&loop_ops);
out_release_core_bus:
tcm_loop_release_core_bus();
out_destroy_cache:
@@ -1304,6 +1317,7 @@ out:
static void __exit tcm_loop_fabric_exit(void)
{
+ sas_release_transport(tcm_loop_sas_transport_template);
target_unregister_template(&loop_ops);
tcm_loop_release_core_bus();
kmem_cache_destroy(tcm_loop_cmd_cache);
--
1.8.5.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 2/8] tcm_loop: Add SAS transport topology
2015-06-18 9:43 [PATCH 0/8] tcm_loop updates Hannes Reinecke
2015-06-18 9:43 ` [PATCH 1/8] tcm_loop: Hook into SAS transport class Hannes Reinecke
@ 2015-06-18 9:43 ` Hannes Reinecke
2015-06-18 9:43 ` [PATCH 3/8] tcm_loop: Remove SAS vestigies Hannes Reinecke
` (6 subsequent siblings)
8 siblings, 0 replies; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-18 9:43 UTC (permalink / raw)
To: Nic Bellinger
Cc: target-devel, linux-scsi, Christoph Hellwig, Ewan Milne,
Hannes Reinecke
As tcm_loop emulates a SAS HBA it should not only
attach to the SAS transport template but also
populate the SAS device hierarchy.
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
drivers/target/loopback/tcm_loop.c | 139 ++++++++++++++++++++++++++++++++-----
drivers/target/loopback/tcm_loop.h | 3 +
2 files changed, 125 insertions(+), 17 deletions(-)
diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c
index 45ae3e4..7d436db 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -439,6 +439,9 @@ static int tcm_loop_driver_remove(struct device *dev)
tl_hba = to_tcm_loop_hba(dev);
sh = tl_hba->sh;
+ if (tl_hba->tl_proto_id == SCSI_PROTOCOL_SAS)
+ sas_remove_host(sh);
+
scsi_remove_host(sh);
scsi_host_put(sh);
return 0;
@@ -729,10 +732,18 @@ static int tcm_loop_port_link(
struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba;
atomic_inc_mb(&tl_tpg->tl_tpg_port_count);
- /*
- * Add Linux/SCSI struct scsi_device by HCTL
- */
- scsi_add_device(tl_hba->sh, 0, tl_tpg->tl_tpgt, lun->unpacked_lun);
+ if (tl_hba->tl_proto_id != SCSI_PROTOCOL_SAS) {
+ /*
+ * Add Linux/SCSI struct scsi_device by HCTL
+ */
+ scsi_add_device(tl_hba->sh, 0,
+ tl_tpg->tl_tpgt, lun->unpacked_lun);
+ } else {
+ struct sas_rphy *rphy = tl_tpg->sas_rphy;
+
+ scsi_scan_target(&rphy->dev, 0, rphy->scsi_target_id,
+ lun->unpacked_lun, 0);
+ }
pr_debug("TCM_Loop_ConfigFS: Port Link Successful\n");
return 0;
@@ -749,19 +760,21 @@ static void tcm_loop_port_unlink(
tl_tpg = container_of(se_tpg, struct tcm_loop_tpg, tl_se_tpg);
tl_hba = tl_tpg->tl_hba;
- sd = scsi_device_lookup(tl_hba->sh, 0, tl_tpg->tl_tpgt,
- se_lun->unpacked_lun);
- if (!sd) {
- pr_err("Unable to locate struct scsi_device for %d:%d:"
- "%llu\n", 0, tl_tpg->tl_tpgt, se_lun->unpacked_lun);
- return;
+ if (tl_hba->tl_proto_id != SCSI_PROTOCOL_SAS) {
+ sd = scsi_device_lookup(tl_hba->sh, 0, tl_tpg->tl_tpgt,
+ se_lun->unpacked_lun);
+ if (!sd) {
+ pr_err("Unable to locate struct scsi_device for %d:%d:"
+ "%llu\n", 0, tl_tpg->tl_tpgt,
+ se_lun->unpacked_lun);
+ return;
+ }
+ /*
+ * Remove Linux/SCSI struct scsi_device by HCTL
+ */
+ scsi_remove_device(sd);
+ scsi_device_put(sd);
}
- /*
- * Remove Linux/SCSI struct scsi_device by HCTL
- */
- scsi_remove_device(sd);
- scsi_device_put(sd);
-
atomic_dec_mb(&tl_tpg->tl_tpg_port_count);
pr_debug("TCM_Loop_ConfigFS: Port Unlink Successful\n");
@@ -858,6 +871,33 @@ static int tcm_loop_make_nexus(
pr_debug("TCM_Loop_ConfigFS: Established I_T Nexus to emulated"
" %s Initiator Port: %s\n", tcm_loop_dump_proto_id(tl_hba),
name);
+
+ if (tl_hba->tl_proto_id == SCSI_PROTOCOL_SAS) {
+ struct Scsi_Host *sh = tl_hba->sh;
+ u64 sas_address;
+
+ if (kstrtoull(name, 16, &sas_address)) {
+ pr_err("Invalid SAS address %s\n", name);
+ return -ENODEV;
+ }
+ tl_nexus->sas_phy = sas_phy_alloc(&sh->shost_gendev,
+ tl_tpg->tl_tpgt);
+ if (!tl_nexus->sas_phy) {
+ pr_err("Unable to allocate SAS host phy\n");
+ return -ENOMEM;
+ }
+ tl_nexus->sas_phy->identify.sas_address = sas_address;
+ tl_nexus->sas_phy->identify.phy_identifier = 0;
+ tl_nexus->sas_phy->identify.device_type = SAS_END_DEVICE;
+ tl_nexus->sas_phy->identify.initiator_port_protocols = SAS_PROTOCOL_STP|SAS_PROTOCOL_SMP;
+ if (sas_phy_add(tl_nexus->sas_phy)) {
+ sas_phy_free(tl_nexus->sas_phy);
+ tl_nexus->sas_phy = NULL;
+ pr_err("Unable to add SAS host phy\n");
+ return -ENODEV;
+ }
+ sas_port_add_phy(tl_tpg->sas_port, tl_nexus->sas_phy);
+ }
return 0;
out:
@@ -886,6 +926,13 @@ static int tcm_loop_drop_nexus(
return -EPERM;
}
+ if (tl_nexus->sas_phy) {
+ sas_port_delete_phy(tpg->sas_port, tl_nexus->sas_phy);
+ sas_phy_delete(tl_nexus->sas_phy);
+ sas_phy_free(tl_nexus->sas_phy);
+ tl_nexus->sas_phy = NULL;
+ }
+
pr_debug("TCM_Loop_ConfigFS: Removing I_T Nexus to emulated"
" %s Initiator Port: %s\n", tcm_loop_dump_proto_id(tpg->tl_hba),
tl_nexus->se_sess->se_node_acl->initiatorname);
@@ -956,7 +1003,7 @@ static ssize_t tcm_loop_tpg_store_nexus(
tcm_loop_dump_proto_id(tl_hba));
return -EINVAL;
}
- port_ptr = &i_port[0];
+ port_ptr = &i_port[4];
goto check_newline;
}
ptr = strstr(i_port, "fc.");
@@ -1089,6 +1136,48 @@ static struct se_portal_group *tcm_loop_make_naa_tpg(
if (ret < 0)
return ERR_PTR(-ENOMEM);
+ if (tl_hba->tl_proto_id == SCSI_PROTOCOL_SAS) {
+ struct Scsi_Host *sh = tl_hba->sh;
+ u64 sas_address;
+
+ tl_tpg->sas_port = sas_port_alloc(&sh->shost_gendev, tpgt);
+ if (!tl_tpg->sas_port) {
+ pr_err("Unable to allocate SAS port %ld\n", tpgt);
+ return ERR_PTR(-ENOMEM);
+ }
+ if ((sas_port_add(tl_tpg->sas_port))) {
+ sas_port_free(tl_tpg->sas_port);
+ tl_tpg->sas_port = NULL;
+ pr_err("Unable to add SAS port %ld\n", tpgt);
+ return ERR_PTR(-ENODEV);
+ }
+ if (kstrtoull(tl_hba->tl_wwn_address, 16, &sas_address)) {
+ pr_err("Invalid SAS address %s\n",
+ tl_hba->tl_wwn_address);
+ sas_port_free(tl_tpg->sas_port);
+ tl_tpg->sas_port = NULL;
+ return ERR_PTR(-ENODEV);
+ }
+ tl_tpg->sas_rphy = sas_end_device_alloc(tl_tpg->sas_port);
+ if (!tl_tpg->sas_rphy) {
+ pr_err("Unable to allocate SAS end device\n");
+ sas_port_free(tl_tpg->sas_port);
+ tl_tpg->sas_port = NULL;
+ return ERR_PTR(-ENOMEM);
+ }
+ tl_tpg->sas_rphy->identify.sas_address = sas_address;
+ tl_tpg->sas_rphy->identify.phy_identifier = 0;
+ tl_tpg->sas_rphy->identify.device_type = SAS_END_DEVICE;
+ tl_tpg->sas_rphy->identify.target_port_protocols = SAS_PROTOCOL_STP|SAS_PROTOCOL_SMP;
+ if (sas_rphy_add(tl_tpg->sas_rphy)) {
+ sas_rphy_free(tl_tpg->sas_rphy);
+ tl_tpg->sas_rphy = NULL;
+ sas_port_free(tl_tpg->sas_port);
+ tl_tpg->sas_port = NULL;
+ pr_err("Unable to add SAS target phy\n");
+ return ERR_PTR(-ENODEV);
+ }
+ }
pr_debug("TCM_Loop_ConfigFS: Allocated Emulated %s"
" Target Port %s,t,0x%04lx\n", tcm_loop_dump_proto_id(tl_hba),
config_item_name(&wwn->wwn_group.cg_item), tpgt);
@@ -1107,10 +1196,25 @@ static void tcm_loop_drop_naa_tpg(
tl_hba = tl_tpg->tl_hba;
tpgt = tl_tpg->tl_tpgt;
+
+ if (tl_hba->tl_proto_id == SCSI_PROTOCOL_SAS)
+ sas_rphy_delete(tl_tpg->sas_rphy);
+
/*
* Release the I_T Nexus for the Virtual SAS link if present
*/
tcm_loop_drop_nexus(tl_tpg);
+
+ if (tl_tpg->sas_rphy) {
+ sas_rphy_delete(tl_tpg->sas_rphy);
+ tl_tpg->sas_rphy = NULL;
+ }
+
+ if (tl_tpg->sas_port) {
+ sas_port_free(tl_tpg->sas_port);
+ tl_tpg->sas_port = NULL;
+ }
+
/*
* Deregister the tl_tpg as a emulated SAS TCM Target Endpoint
*/
@@ -1150,6 +1254,7 @@ static struct se_wwn *tcm_loop_make_scsi_hba(
ptr = strstr(name, "naa.");
if (ptr) {
tl_hba->tl_proto_id = SCSI_PROTOCOL_SAS;
+ off = 4; /* Skip over "naa." */
goto check_len;
}
ptr = strstr(name, "fc.");
diff --git a/drivers/target/loopback/tcm_loop.h b/drivers/target/loopback/tcm_loop.h
index 4346462..2d4c22d 100644
--- a/drivers/target/loopback/tcm_loop.h
+++ b/drivers/target/loopback/tcm_loop.h
@@ -26,6 +26,7 @@ struct tcm_loop_nexus {
* Pointer to TCM session for I_T Nexus
*/
struct se_session *se_sess;
+ struct sas_phy *sas_phy;
};
#define TCM_TRANSPORT_ONLINE 0
@@ -39,6 +40,8 @@ struct tcm_loop_tpg {
struct se_portal_group tl_se_tpg;
struct tcm_loop_hba *tl_hba;
struct tcm_loop_nexus *tl_nexus;
+ struct sas_port *sas_port;
+ struct sas_rphy *sas_rphy;
};
struct tcm_loop_hba {
--
1.8.5.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 3/8] tcm_loop: Remove SAS vestigies
2015-06-18 9:43 [PATCH 0/8] tcm_loop updates Hannes Reinecke
2015-06-18 9:43 ` [PATCH 1/8] tcm_loop: Hook into SAS transport class Hannes Reinecke
2015-06-18 9:43 ` [PATCH 2/8] tcm_loop: Add SAS transport topology Hannes Reinecke
@ 2015-06-18 9:43 ` Hannes Reinecke
2015-06-18 9:43 ` [PATCH 4/8] tcm_loop: Send I_T_NEXUS_LOSS_OCCURRED UA Hannes Reinecke
` (5 subsequent siblings)
8 siblings, 0 replies; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-18 9:43 UTC (permalink / raw)
To: Nic Bellinger
Cc: target-devel, linux-scsi, Christoph Hellwig, Ewan Milne,
Hannes Reinecke
tcm_loop is able to emulate several protocols, so remove last
vestigies of the SAS protocol.
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
drivers/target/loopback/tcm_loop.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c
index 7d436db..d77caf5 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -535,7 +535,7 @@ static inline struct tcm_loop_tpg *tl_tpg(struct se_portal_group *se_tpg)
static char *tcm_loop_get_endpoint_wwn(struct se_portal_group *se_tpg)
{
/*
- * Return the passed NAA identifier for the SAS Target Port
+ * Return the passed NAA identifier for the Target Port
*/
return &tl_tpg(se_tpg)->tl_hba->tl_wwn_address[0];
}
@@ -864,7 +864,7 @@ static int tcm_loop_make_nexus(
transport_free_session(tl_nexus->se_sess);
goto out;
}
- /* Now, register the SAS I_T Nexus as active. */
+ /* Now, register the I_T Nexus as active. */
transport_register_session(se_tpg, tl_nexus->se_sess->se_node_acl,
tl_nexus->se_sess, tl_nexus);
tl_tpg->tl_nexus = tl_nexus;
@@ -937,7 +937,7 @@ static int tcm_loop_drop_nexus(
" %s Initiator Port: %s\n", tcm_loop_dump_proto_id(tpg->tl_hba),
tl_nexus->se_sess->se_node_acl->initiatorname);
/*
- * Release the SCSI I_T Nexus to the emulated SAS Target Port
+ * Release the SCSI I_T Nexus to the emulated Target Port
*/
transport_deregister_session(tl_nexus->se_sess);
tpg->tl_nexus = NULL;
@@ -1130,7 +1130,7 @@ static struct se_portal_group *tcm_loop_make_naa_tpg(
tl_tpg->tl_hba = tl_hba;
tl_tpg->tl_tpgt = tpgt;
/*
- * Register the tl_tpg as a emulated SAS TCM Target Endpoint
+ * Register the tl_tpg as a emulated TCM Target Endpoint
*/
ret = core_tpg_register(wwn, &tl_tpg->tl_se_tpg, tl_hba->tl_proto_id);
if (ret < 0)
@@ -1201,7 +1201,7 @@ static void tcm_loop_drop_naa_tpg(
sas_rphy_delete(tl_tpg->sas_rphy);
/*
- * Release the I_T Nexus for the Virtual SAS link if present
+ * Release the I_T Nexus for the Virtual target link if present
*/
tcm_loop_drop_nexus(tl_tpg);
@@ -1216,7 +1216,7 @@ static void tcm_loop_drop_naa_tpg(
}
/*
- * Deregister the tl_tpg as a emulated SAS TCM Target Endpoint
+ * Deregister the tl_tpg as a emulated TCM Target Endpoint
*/
core_tpg_deregister(se_tpg);
@@ -1310,8 +1310,9 @@ static void tcm_loop_drop_scsi_hba(
struct tcm_loop_hba, tl_hba_wwn);
pr_debug("TCM_Loop_ConfigFS: Deallocating emulated Target"
- " SAS Address: %s at Linux/SCSI Host ID: %d\n",
- tl_hba->tl_wwn_address, tl_hba->sh->host_no);
+ " %s Address: %s at Linux/SCSI Host ID: %d\n",
+ tcm_loop_dump_proto_id(tl_hba), tl_hba->tl_wwn_address,
+ tl_hba->sh->host_no);
/*
* Call device_unregister() on the original tl_hba->dev.
* tcm_loop_fabric_scsi.c:tcm_loop_release_adapter() will
--
1.8.5.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 4/8] tcm_loop: Send I_T_NEXUS_LOSS_OCCURRED UA
2015-06-18 9:43 [PATCH 0/8] tcm_loop updates Hannes Reinecke
` (2 preceding siblings ...)
2015-06-18 9:43 ` [PATCH 3/8] tcm_loop: Remove SAS vestigies Hannes Reinecke
@ 2015-06-18 9:43 ` Hannes Reinecke
2015-06-18 9:43 ` [PATCH 5/8] tcm_loop: Rescan SCSI target on transport online Hannes Reinecke
` (4 subsequent siblings)
8 siblings, 0 replies; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-18 9:43 UTC (permalink / raw)
To: Nic Bellinger
Cc: target-devel, linux-scsi, Christoph Hellwig, Ewan Milne,
Hannes Reinecke
If the virtual SAS link is set to 'offline' we should be
queueing an I_T_NEXUS_LOSS_OCCURRED UA.
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
drivers/target/loopback/tcm_loop.c | 5 +++++
drivers/target/target_core_tpg.c | 17 +++++++++++++++++
include/target/target_core_fabric.h | 1 +
3 files changed, 23 insertions(+)
diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c
index d77caf5..6c724dd 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -1087,6 +1087,11 @@ static ssize_t tcm_loop_tpg_store_transport_status(
}
if (!strncmp(page, "offline", 7)) {
tl_tpg->tl_transport_status = TCM_TRANSPORT_OFFLINE;
+ if (tl_tpg->tl_nexus) {
+ struct se_session *tl_sess = tl_tpg->tl_nexus->se_sess;
+
+ core_allocate_nexus_loss_ua(tl_sess->se_node_acl);
+ }
return count;
}
return -EINVAL;
diff --git a/drivers/target/target_core_tpg.c b/drivers/target/target_core_tpg.c
index aa39bc8..94c531e 100644
--- a/drivers/target/target_core_tpg.c
+++ b/drivers/target/target_core_tpg.c
@@ -43,6 +43,7 @@
#include "target_core_internal.h"
#include "target_core_alua.h"
#include "target_core_pr.h"
+#include "target_core_ua.h"
extern struct se_device *g_lun0_dev;
@@ -85,6 +86,22 @@ struct se_node_acl *core_tpg_get_initiator_node_acl(
}
EXPORT_SYMBOL(core_tpg_get_initiator_node_acl);
+void core_allocate_nexus_loss_ua(
+ struct se_node_acl *nacl)
+{
+ struct se_dev_entry *deve;
+
+ if (!nacl)
+ return;
+
+ rcu_read_lock();
+ hlist_for_each_entry_rcu(deve, &nacl->lun_entry_hlist, link)
+ core_scsi3_ua_allocate(deve, 0x29,
+ ASCQ_29H_NEXUS_LOSS_OCCURRED);
+ rcu_read_unlock();
+}
+EXPORT_SYMBOL(core_allocate_nexus_loss_ua);
+
/* core_tpg_add_node_to_devs():
*
*
diff --git a/include/target/target_core_fabric.h b/include/target/target_core_fabric.h
index 18afef9..69355fe 100644
--- a/include/target/target_core_fabric.h
+++ b/include/target/target_core_fabric.h
@@ -152,6 +152,7 @@ int transport_generic_handle_tmr(struct se_cmd *);
void transport_generic_request_failure(struct se_cmd *, sense_reason_t);
void __target_execute_cmd(struct se_cmd *);
int transport_lookup_tmr_lun(struct se_cmd *, u64);
+void core_allocate_nexus_loss_ua(struct se_node_acl *acl);
struct se_node_acl *core_tpg_get_initiator_node_acl(struct se_portal_group *tpg,
unsigned char *);
--
1.8.5.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 5/8] tcm_loop: Rescan SCSI target on transport online
2015-06-18 9:43 [PATCH 0/8] tcm_loop updates Hannes Reinecke
` (3 preceding siblings ...)
2015-06-18 9:43 ` [PATCH 4/8] tcm_loop: Send I_T_NEXUS_LOSS_OCCURRED UA Hannes Reinecke
@ 2015-06-18 9:43 ` Hannes Reinecke
2015-06-18 9:43 ` [PATCH 6/8] target: Issue Power-On/Reset UA upon LUN instantiation Hannes Reinecke
` (3 subsequent siblings)
8 siblings, 0 replies; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-18 9:43 UTC (permalink / raw)
To: Nic Bellinger
Cc: target-devel, linux-scsi, Christoph Hellwig, Ewan Milne,
Hannes Reinecke
Setting the transport status to 'online' needs to rescan the
target, as some devices might have been added while the transport
has been offline.
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
drivers/target/loopback/tcm_loop.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c
index 6c724dd..7db31f3 100644
--- a/drivers/target/loopback/tcm_loop.c
+++ b/drivers/target/loopback/tcm_loop.c
@@ -1082,7 +1082,16 @@ static ssize_t tcm_loop_tpg_store_transport_status(
struct tcm_loop_tpg, tl_se_tpg);
if (!strncmp(page, "online", 6)) {
+ int status = tl_tpg->tl_transport_status;
+
tl_tpg->tl_transport_status = TCM_TRANSPORT_ONLINE;
+ if (status != tl_tpg->tl_transport_status &&
+ tl_tpg->tl_hba->tl_proto_id == SCSI_PROTOCOL_SAS) {
+ struct sas_rphy *rphy = tl_tpg->sas_rphy;
+
+ scsi_scan_target(&rphy->dev, 0, rphy->scsi_target_id,
+ SCAN_WILD_CARD, 0);
+ }
return count;
}
if (!strncmp(page, "offline", 7)) {
--
1.8.5.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 6/8] target: Issue Power-On/Reset UA upon LUN instantiation
2015-06-18 9:43 [PATCH 0/8] tcm_loop updates Hannes Reinecke
` (4 preceding siblings ...)
2015-06-18 9:43 ` [PATCH 5/8] tcm_loop: Rescan SCSI target on transport online Hannes Reinecke
@ 2015-06-18 9:43 ` Hannes Reinecke
2015-06-18 9:43 ` [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby Hannes Reinecke
` (2 subsequent siblings)
8 siblings, 0 replies; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-18 9:43 UTC (permalink / raw)
To: Nic Bellinger
Cc: target-devel, linux-scsi, Christoph Hellwig, Ewan Milne,
Hannes Reinecke
Whenever a LUN is being assigned we should be sending out an
Power-On/Reset UA.
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
drivers/target/target_core_device.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c
index 52676a0..88d6070 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -363,9 +363,11 @@ int core_enable_device_list_for_node(
rcu_read_lock();
hlist_for_each_entry_rcu(tmp, &nacl->lun_entry_hlist, link) {
if (tmp == new)
- continue;
- core_scsi3_ua_allocate(tmp, 0x3F,
- ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
+ core_scsi3_ua_allocate(tmp, 0x29,
+ ASCQ_29H_POWER_ON_RESET_OR_BUS_DEVICE_RESET_OCCURED);
+ else
+ core_scsi3_ua_allocate(tmp, 0x3F,
+ ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
}
rcu_read_unlock();
@@ -385,9 +387,11 @@ int core_enable_device_list_for_node(
rcu_read_lock();
hlist_for_each_entry_rcu(tmp, &nacl->lun_entry_hlist, link) {
if (tmp == new)
- continue;
- core_scsi3_ua_allocate(tmp, 0x3F,
- ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
+ core_scsi3_ua_allocate(tmp, 0x29,
+ ASCQ_29H_POWER_ON_RESET_OR_BUS_DEVICE_RESET_OCCURED);
+ else
+ core_scsi3_ua_allocate(tmp, 0x3F,
+ ASCQ_3FH_REPORTED_LUNS_DATA_HAS_CHANGED);
}
rcu_read_unlock();
return 0;
--
1.8.5.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby
2015-06-18 9:43 [PATCH 0/8] tcm_loop updates Hannes Reinecke
` (5 preceding siblings ...)
2015-06-18 9:43 ` [PATCH 6/8] target: Issue Power-On/Reset UA upon LUN instantiation Hannes Reinecke
@ 2015-06-18 9:43 ` Hannes Reinecke
2015-06-18 11:40 ` Chris Boot
2015-06-19 6:49 ` Christoph Hellwig
2015-06-18 9:43 ` [PATCH 8/8] target: display 'write_protect' attribute for demo-mode LUNs Hannes Reinecke
2015-06-19 6:48 ` [PATCH 0/8] tcm_loop updates Christoph Hellwig
8 siblings, 2 replies; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-18 9:43 UTC (permalink / raw)
To: Nic Bellinger
Cc: target-devel, linux-scsi, Christoph Hellwig, Ewan Milne,
Hannes Reinecke
Strictly speaking SPC doesn't require READ CAPACITY and friends
to be supported while in the port is in standby.
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
drivers/target/target_core_alua.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/drivers/target/target_core_alua.c b/drivers/target/target_core_alua.c
index edaf1b9..a62e58b 100644
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -561,16 +561,7 @@ static inline int core_alua_state_standby(
case REPORT_LUNS:
case RECEIVE_DIAGNOSTIC:
case SEND_DIAGNOSTIC:
- case READ_CAPACITY:
return 0;
- case SERVICE_ACTION_IN_16:
- switch (cdb[1] & 0x1f) {
- case SAI_READ_CAPACITY_16:
- return 0;
- default:
- set_ascq(cmd, ASCQ_04H_ALUA_TG_PT_STANDBY);
- return 1;
- }
case MAINTENANCE_IN:
switch (cdb[1] & 0x1f) {
case MI_REPORT_TARGET_PGS:
--
1.8.5.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby
2015-06-18 9:43 ` [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby Hannes Reinecke
@ 2015-06-18 11:40 ` Chris Boot
2015-06-18 14:32 ` Hannes Reinecke
2015-06-19 6:49 ` Christoph Hellwig
1 sibling, 1 reply; 24+ messages in thread
From: Chris Boot @ 2015-06-18 11:40 UTC (permalink / raw)
To: Hannes Reinecke, Nic Bellinger
Cc: target-devel, linux-scsi, Christoph Hellwig, Ewan Milne
On 18/06/15 10:43, Hannes Reinecke wrote:
> Strictly speaking SPC doesn't require READ CAPACITY and friends
> to be supported while in the port is in standby.
Hi Hannes,
I'd really rather this didn't go away. Yes, strictly speaking SPC
doesn't require these commands but Linux in practice does, and ISTR this
was added at my request too.
We need it on our storage setups to prevent the Linux SCSI stack from
exploding. If this is removed here, they'll start exploding again until
the fix goes in and the initiators are updated.
Could this please be kept as an option or something?
Cheers,
Chris
> Signed-off-by: Hannes Reinecke <hare@suse.de>
> ---
> drivers/target/target_core_alua.c | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/target/target_core_alua.c b/drivers/target/target_core_alua.c
> index edaf1b9..a62e58b 100644
> --- a/drivers/target/target_core_alua.c
> +++ b/drivers/target/target_core_alua.c
> @@ -561,16 +561,7 @@ static inline int core_alua_state_standby(
> case REPORT_LUNS:
> case RECEIVE_DIAGNOSTIC:
> case SEND_DIAGNOSTIC:
> - case READ_CAPACITY:
> return 0;
> - case SERVICE_ACTION_IN_16:
> - switch (cdb[1] & 0x1f) {
> - case SAI_READ_CAPACITY_16:
> - return 0;
> - default:
> - set_ascq(cmd, ASCQ_04H_ALUA_TG_PT_STANDBY);
> - return 1;
> - }
> case MAINTENANCE_IN:
> switch (cdb[1] & 0x1f) {
> case MI_REPORT_TARGET_PGS:
>
--
Chris Boot
bootc@bootc.net
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby
2015-06-18 11:40 ` Chris Boot
@ 2015-06-18 14:32 ` Hannes Reinecke
0 siblings, 0 replies; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-18 14:32 UTC (permalink / raw)
To: Chris Boot, Nic Bellinger
Cc: target-devel, linux-scsi, Christoph Hellwig, Ewan Milne
On 06/18/2015 01:40 PM, Chris Boot wrote:
> On 18/06/15 10:43, Hannes Reinecke wrote:
>> Strictly speaking SPC doesn't require READ CAPACITY and friends
>> to be supported while in the port is in standby.
>
> Hi Hannes,
>
> I'd really rather this didn't go away. Yes, strictly speaking SPC
> doesn't require these commands but Linux in practice does, and ISTR this
> was added at my request too.
>
> We need it on our storage setups to prevent the Linux SCSI stack from
> exploding. If this is removed here, they'll start exploding again until
> the fix goes in and the initiators are updated.
>
This was exactly why I added it, so that one could go about and fix
the linux SCSI stack :-)
> Could this please be kept as an option or something?
>
Yeah, I see what I can do.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby
2015-06-18 9:43 ` [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby Hannes Reinecke
2015-06-18 11:40 ` Chris Boot
@ 2015-06-19 6:49 ` Christoph Hellwig
2015-06-19 7:07 ` Hannes Reinecke
1 sibling, 1 reply; 24+ messages in thread
From: Christoph Hellwig @ 2015-06-19 6:49 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Nic Bellinger, target-devel, linux-scsi, Christoph Hellwig,
Ewan Milne
On Thu, Jun 18, 2015 at 11:43:41AM +0200, Hannes Reinecke wrote:
> Strictly speaking SPC doesn't require READ CAPACITY and friends
> to be supported while in the port is in standby.
But it does allow it. We should always aim to implement the best
possible behavior instead of aiming for the worst.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby
2015-06-19 6:49 ` Christoph Hellwig
@ 2015-06-19 7:07 ` Hannes Reinecke
0 siblings, 0 replies; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-19 7:07 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Nic Bellinger, target-devel, linux-scsi, Ewan Milne
On 06/19/2015 08:49 AM, Christoph Hellwig wrote:
> On Thu, Jun 18, 2015 at 11:43:41AM +0200, Hannes Reinecke wrote:
>> Strictly speaking SPC doesn't require READ CAPACITY and friends
>> to be supported while in the port is in standby.
>
> But it does allow it. We should always aim to implement the best
> possible behavior instead of aiming for the worst.
>
Right. As mentioned in my other mail this patch was primarily to
fixup READ CAPACITY issues in the linux kernel.
I'll be updating the patch to make it optional.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 8/8] target: display 'write_protect' attribute for demo-mode LUNs
2015-06-18 9:43 [PATCH 0/8] tcm_loop updates Hannes Reinecke
` (6 preceding siblings ...)
2015-06-18 9:43 ` [PATCH 7/8] target_core_alua: disallow READ_CAPACITY when in standby Hannes Reinecke
@ 2015-06-18 9:43 ` Hannes Reinecke
2015-06-19 6:51 ` Christoph Hellwig
2015-06-19 6:48 ` [PATCH 0/8] tcm_loop updates Christoph Hellwig
8 siblings, 1 reply; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-18 9:43 UTC (permalink / raw)
To: Nic Bellinger
Cc: target-devel, linux-scsi, Christoph Hellwig, Ewan Milne,
Hannes Reinecke
When LUNs are mapped with a demo-mode initiator we're missing
the 'write_protect' attribute to set a LUN read-only.
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
drivers/target/target_core_device.c | 27 ++++++++++++++++++
drivers/target/target_core_fabric_configfs.c | 42 ++++++++++++++++++++++++++++
drivers/target/target_core_internal.h | 1 +
3 files changed, 70 insertions(+)
diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c
index 88d6070..3e17070 100644
--- a/drivers/target/target_core_device.c
+++ b/drivers/target/target_core_device.c
@@ -271,6 +271,33 @@ void core_update_device_list_access(
mutex_unlock(&nacl->lun_entry_mutex);
}
+void core_update_lun_access(
+ struct se_lun *lun,
+ u32 lun_access)
+{
+ struct se_dev_entry *deve;
+
+ if (lun_access == TRANSPORT_LUNFLAGS_READ_ONLY) {
+ lun->lun_access &= ~TRANSPORT_LUNFLAGS_READ_WRITE;
+ lun->lun_access |= TRANSPORT_LUNFLAGS_READ_ONLY;
+ } else {
+ lun->lun_access &= ~TRANSPORT_LUNFLAGS_READ_ONLY;
+ lun->lun_access |= TRANSPORT_LUNFLAGS_READ_WRITE;
+ }
+
+ spin_lock_bh(&lun->lun_deve_lock);
+ list_for_each_entry(deve, &lun->lun_deve_list, lun_link) {
+ if (lun_access & TRANSPORT_LUNFLAGS_READ_WRITE) {
+ deve->lun_flags &= ~TRANSPORT_LUNFLAGS_READ_ONLY;
+ deve->lun_flags |= TRANSPORT_LUNFLAGS_READ_WRITE;
+ } else {
+ deve->lun_flags &= ~TRANSPORT_LUNFLAGS_READ_WRITE;
+ deve->lun_flags |= TRANSPORT_LUNFLAGS_READ_ONLY;
+ }
+ }
+ spin_unlock_bh(&lun->lun_deve_lock);
+}
+
/*
* Called with rcu_read_lock or nacl->device_list_lock held.
*/
diff --git a/drivers/target/target_core_fabric_configfs.c b/drivers/target/target_core_fabric_configfs.c
index 6cfee59..299b4b5 100644
--- a/drivers/target/target_core_fabric_configfs.c
+++ b/drivers/target/target_core_fabric_configfs.c
@@ -726,12 +726,54 @@ static ssize_t target_fabric_port_store_attr_alua_tg_pt_write_md(
TCM_PORT_ATTR(alua_tg_pt_write_md, S_IRUGO | S_IWUSR);
+static ssize_t target_fabric_port_show_attr_write_protect(
+ struct se_lun *lun,
+ char *page)
+{
+ ssize_t len = 0;
+
+ if (!lun || !lun->lun_se_dev)
+ return -ENODEV;
+
+ len = sprintf(page, "%d\n",
+ (lun->lun_access & TRANSPORT_LUNFLAGS_READ_ONLY) ? 1 : 0);
+
+ return len;
+}
+
+static ssize_t target_fabric_port_store_attr_write_protect(
+ struct se_lun *lun,
+ const char *page,
+ size_t count)
+{
+ unsigned long op;
+ int ret;
+
+ if (!lun || !lun->lun_se_dev)
+ return -ENODEV;
+
+ ret = kstrtoul(page, 0, &op);
+ if (ret)
+ return ret;
+
+ if ((op != 1) && (op != 0))
+ return -EINVAL;
+
+ core_update_lun_access(lun, (op) ?
+ TRANSPORT_LUNFLAGS_READ_ONLY :
+ TRANSPORT_LUNFLAGS_READ_WRITE);
+
+ return count;
+
+}
+TCM_PORT_ATTR(write_protect, S_IRUGO | S_IWUSR);
static struct configfs_attribute *target_fabric_port_attrs[] = {
&target_fabric_port_alua_tg_pt_gp.attr,
&target_fabric_port_alua_tg_pt_offline.attr,
&target_fabric_port_alua_tg_pt_status.attr,
&target_fabric_port_alua_tg_pt_write_md.attr,
+ &target_fabric_port_write_protect.attr,
NULL,
};
diff --git a/drivers/target/target_core_internal.h b/drivers/target/target_core_internal.h
index 5111789..69a57a4 100644
--- a/drivers/target/target_core_internal.h
+++ b/drivers/target/target_core_internal.h
@@ -36,6 +36,7 @@ void core_clear_lun_from_tpg(struct se_lun *, struct se_portal_group *);
int core_dev_add_lun(struct se_portal_group *, struct se_device *,
struct se_lun *lun);
void core_dev_del_lun(struct se_portal_group *, struct se_lun *);
+void core_update_lun_access(struct se_lun *, u32);
struct se_lun_acl *core_dev_init_initiator_node_lun_acl(struct se_portal_group *,
struct se_node_acl *, u64, int *);
int core_dev_add_initiator_node_lun_acl(struct se_portal_group *,
--
1.8.5.2
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH 8/8] target: display 'write_protect' attribute for demo-mode LUNs
2015-06-18 9:43 ` [PATCH 8/8] target: display 'write_protect' attribute for demo-mode LUNs Hannes Reinecke
@ 2015-06-19 6:51 ` Christoph Hellwig
2015-06-19 7:05 ` Hannes Reinecke
0 siblings, 1 reply; 24+ messages in thread
From: Christoph Hellwig @ 2015-06-19 6:51 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Nic Bellinger, target-devel, linux-scsi, Christoph Hellwig,
Ewan Milne
On Thu, Jun 18, 2015 at 11:43:42AM +0200, Hannes Reinecke wrote:
> When LUNs are mapped with a demo-mode initiator we're missing
> the 'write_protect' attribute to set a LUN read-only.
I don't think it's a good idea as-is. The target core clearly
differenciates between demo mode and production mode read only, and some
drivers already expose attributes for these.
I have a big series in progress to clean the mess around this area
up. So for now please don't add anything here, it should become much
simpler after my changes, and I might be able to incorporate something
like this after the main series.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 8/8] target: display 'write_protect' attribute for demo-mode LUNs
2015-06-19 6:51 ` Christoph Hellwig
@ 2015-06-19 7:05 ` Hannes Reinecke
0 siblings, 0 replies; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-19 7:05 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Nic Bellinger, target-devel, linux-scsi, Ewan Milne
On 06/19/2015 08:51 AM, Christoph Hellwig wrote:
> On Thu, Jun 18, 2015 at 11:43:42AM +0200, Hannes Reinecke wrote:
>> When LUNs are mapped with a demo-mode initiator we're missing
>> the 'write_protect' attribute to set a LUN read-only.
>
> I don't think it's a good idea as-is. The target core clearly
> differenciates between demo mode and production mode read only, and some
> drivers already expose attributes for these.
>
> I have a big series in progress to clean the mess around this area
> up. So for now please don't add anything here, it should become much
> simpler after my changes, and I might be able to incorporate something
> like this after the main series.
>
I've done this particular patch to simulate write-protected LUNs via
tcm_loop. As the hooks already had been there I thought this to be
the 'cleanest' approach.
Of course, if you have other suggestions on how this should be
achieved I'm happy to try this.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/8] tcm_loop updates
2015-06-18 9:43 [PATCH 0/8] tcm_loop updates Hannes Reinecke
` (7 preceding siblings ...)
2015-06-18 9:43 ` [PATCH 8/8] target: display 'write_protect' attribute for demo-mode LUNs Hannes Reinecke
@ 2015-06-19 6:48 ` Christoph Hellwig
2015-06-19 7:13 ` Hannes Reinecke
8 siblings, 1 reply; 24+ messages in thread
From: Christoph Hellwig @ 2015-06-19 6:48 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Nic Bellinger, target-devel, linux-scsi, Christoph Hellwig,
Ewan Milne
What's the benefit of the SAS transport class writeout? I honestly
always saw tcm_loop as a simple loopback driver, with the different
transport IDs in the PR code as a gimmick. Note that vhost and
xen-blkback copies that style and I did plan to consolidate it
in common code.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 0/8] tcm_loop updates
2015-06-19 6:48 ` [PATCH 0/8] tcm_loop updates Christoph Hellwig
@ 2015-06-19 7:13 ` Hannes Reinecke
2015-06-23 8:29 ` Nicholas A. Bellinger
0 siblings, 1 reply; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-19 7:13 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Nic Bellinger, target-devel, linux-scsi, Ewan Milne
On 06/19/2015 08:48 AM, Christoph Hellwig wrote:
> What's the benefit of the SAS transport class writeout? I honestly
> always saw tcm_loop as a simple loopback driver, with the different
> transport IDs in the PR code as a gimmick. Note that vhost and
> xen-blkback copies that style and I did plan to consolidate it
> in common code.
>
The benefit is that tcm_loop will show up in the system as a 'real'
SAS hba; long-term goal is to simulate SAS multipathing here.
I was even planning on adding simlated FC infrastructure, too;
with that we could simulate FC multipathing, too, and our QA would
be _so_ happy...
Again, these patches are mainly a collection of patches I've done to
test various scenarios, in the hope others might find them useful,
too. So I can easily hold off these patches until you've posted your
rework.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/8] tcm_loop updates
2015-06-19 7:13 ` Hannes Reinecke
@ 2015-06-23 8:29 ` Nicholas A. Bellinger
2015-06-23 9:05 ` Hannes Reinecke
0 siblings, 1 reply; 24+ messages in thread
From: Nicholas A. Bellinger @ 2015-06-23 8:29 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Christoph Hellwig, Nic Bellinger, target-devel, linux-scsi,
Ewan Milne
On Fri, 2015-06-19 at 09:13 +0200, Hannes Reinecke wrote:
> On 06/19/2015 08:48 AM, Christoph Hellwig wrote:
> > What's the benefit of the SAS transport class writeout? I honestly
> > always saw tcm_loop as a simple loopback driver, with the different
> > transport IDs in the PR code as a gimmick. Note that vhost and
> > xen-blkback copies that style and I did plan to consolidate it
> > in common code.
> >
> The benefit is that tcm_loop will show up in the system as a 'real'
> SAS hba; long-term goal is to simulate SAS multipathing here.
> I was even planning on adding simlated FC infrastructure, too;
> with that we could simulate FC multipathing, too, and our QA would
> be _so_ happy...
>
Sounds like a reasonable use-case to support for loopback testing.
> Again, these patches are mainly a collection of patches I've done to
> test various scenarios, in the hope others might find them useful,
> too. So I can easily hold off these patches until you've posted your
> rework.
>
How different do you expect sas, fc, and iscsi transports to be..?
Do you think this would this be better served by a simple tcm_loop LLD
specific API for different multipath transports..?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/8] tcm_loop updates
2015-06-23 8:29 ` Nicholas A. Bellinger
@ 2015-06-23 9:05 ` Hannes Reinecke
2015-07-07 0:25 ` Nicholas A. Bellinger
0 siblings, 1 reply; 24+ messages in thread
From: Hannes Reinecke @ 2015-06-23 9:05 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Christoph Hellwig, Nic Bellinger, target-devel, linux-scsi,
Ewan Milne
On 06/23/2015 10:29 AM, Nicholas A. Bellinger wrote:
> On Fri, 2015-06-19 at 09:13 +0200, Hannes Reinecke wrote:
>> On 06/19/2015 08:48 AM, Christoph Hellwig wrote:
>>> What's the benefit of the SAS transport class writeout? I honestly
>>> always saw tcm_loop as a simple loopback driver, with the different
>>> transport IDs in the PR code as a gimmick. Note that vhost and
>>> xen-blkback copies that style and I did plan to consolidate it
>>> in common code.
>>>
>> The benefit is that tcm_loop will show up in the system as a 'real'
>> SAS hba; long-term goal is to simulate SAS multipathing here.
>> I was even planning on adding simlated FC infrastructure, too;
>> with that we could simulate FC multipathing, too, and our QA would
>> be _so_ happy...
>>
>
> Sounds like a reasonable use-case to support for loopback testing.
>
>> Again, these patches are mainly a collection of patches I've done to
>> test various scenarios, in the hope others might find them useful,
>> too. So I can easily hold off these patches until you've posted your
>> rework.
>>
>
> How different do you expect sas, fc, and iscsi transports to be..?
>
> Do you think this would this be better served by a simple tcm_loop LLD
> specific API for different multipath transports..?
>
Actually, I would split off the various transport functions into
separate files (tcm_loop_sas, tcm_loop_fc, etc), but keep a common
tcm_loop module.
We can even make transport classes optional by adding an explicit
'sas.XXX' prefix scanning when creating the device similar to what
we do with the 'fc.XXX' prefix already.
With that we would have a 'sas.XXX', 'fc.XXX', and 'iqn.XXX' WWN
which would attach to the respective transport class, and any other
WWN (which would be the default) would be getting the standard
emulation without any transport class attached.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/8] tcm_loop updates
2015-06-23 9:05 ` Hannes Reinecke
@ 2015-07-07 0:25 ` Nicholas A. Bellinger
2015-07-07 5:50 ` Hannes Reinecke
0 siblings, 1 reply; 24+ messages in thread
From: Nicholas A. Bellinger @ 2015-07-07 0:25 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Christoph Hellwig, Nic Bellinger, target-devel, linux-scsi,
Ewan Milne
On Tue, 2015-06-23 at 11:05 +0200, Hannes Reinecke wrote:
> On 06/23/2015 10:29 AM, Nicholas A. Bellinger wrote:
> > On Fri, 2015-06-19 at 09:13 +0200, Hannes Reinecke wrote:
> >> On 06/19/2015 08:48 AM, Christoph Hellwig wrote:
> >>> What's the benefit of the SAS transport class writeout? I honestly
> >>> always saw tcm_loop as a simple loopback driver, with the different
> >>> transport IDs in the PR code as a gimmick. Note that vhost and
> >>> xen-blkback copies that style and I did plan to consolidate it
> >>> in common code.
> >>>
> >> The benefit is that tcm_loop will show up in the system as a 'real'
> >> SAS hba; long-term goal is to simulate SAS multipathing here.
> >> I was even planning on adding simlated FC infrastructure, too;
> >> with that we could simulate FC multipathing, too, and our QA would
> >> be _so_ happy...
> >>
> >
> > Sounds like a reasonable use-case to support for loopback testing.
> >
> >> Again, these patches are mainly a collection of patches I've done to
> >> test various scenarios, in the hope others might find them useful,
> >> too. So I can easily hold off these patches until you've posted your
> >> rework.
> >>
> >
> > How different do you expect sas, fc, and iscsi transports to be..?
> >
> > Do you think this would this be better served by a simple tcm_loop LLD
> > specific API for different multipath transports..?
> >
> Actually, I would split off the various transport functions into
> separate files (tcm_loop_sas, tcm_loop_fc, etc), but keep a common
> tcm_loop module.
> We can even make transport classes optional by adding an explicit
> 'sas.XXX' prefix scanning when creating the device similar to what
> we do with the 'fc.XXX' prefix already.
> With that we would have a 'sas.XXX', 'fc.XXX', and 'iqn.XXX' WWN
> which would attach to the respective transport class, and any other
> WWN (which would be the default) would be getting the standard
> emulation without any transport class attached.
I'm open to merging the tcm_loop patches #1-#6 as-is for the sas
transport pieces, or wait until you've done a large split based on
transport class types.
It's really your call how the initial merge should look.
--nab
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/8] tcm_loop updates
2015-07-07 0:25 ` Nicholas A. Bellinger
@ 2015-07-07 5:50 ` Hannes Reinecke
2015-07-07 6:26 ` Nicholas A. Bellinger
0 siblings, 1 reply; 24+ messages in thread
From: Hannes Reinecke @ 2015-07-07 5:50 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Christoph Hellwig, Nic Bellinger, target-devel, linux-scsi,
Ewan Milne
On 07/07/2015 02:25 AM, Nicholas A. Bellinger wrote:
> On Tue, 2015-06-23 at 11:05 +0200, Hannes Reinecke wrote:
>> On 06/23/2015 10:29 AM, Nicholas A. Bellinger wrote:
>>> On Fri, 2015-06-19 at 09:13 +0200, Hannes Reinecke wrote:
>>>> On 06/19/2015 08:48 AM, Christoph Hellwig wrote:
>>>>> What's the benefit of the SAS transport class writeout? I honestly
>>>>> always saw tcm_loop as a simple loopback driver, with the different
>>>>> transport IDs in the PR code as a gimmick. Note that vhost and
>>>>> xen-blkback copies that style and I did plan to consolidate it
>>>>> in common code.
>>>>>
>>>> The benefit is that tcm_loop will show up in the system as a 'real'
>>>> SAS hba; long-term goal is to simulate SAS multipathing here.
>>>> I was even planning on adding simlated FC infrastructure, too;
>>>> with that we could simulate FC multipathing, too, and our QA would
>>>> be _so_ happy...
>>>>
>>>
>>> Sounds like a reasonable use-case to support for loopback testing.
>>>
>>>> Again, these patches are mainly a collection of patches I've done to
>>>> test various scenarios, in the hope others might find them useful,
>>>> too. So I can easily hold off these patches until you've posted your
>>>> rework.
>>>>
>>>
>>> How different do you expect sas, fc, and iscsi transports to be..?
>>>
>>> Do you think this would this be better served by a simple tcm_loop LLD
>>> specific API for different multipath transports..?
>>>
>> Actually, I would split off the various transport functions into
>> separate files (tcm_loop_sas, tcm_loop_fc, etc), but keep a common
>> tcm_loop module.
>> We can even make transport classes optional by adding an explicit
>> 'sas.XXX' prefix scanning when creating the device similar to what
>> we do with the 'fc.XXX' prefix already.
>> With that we would have a 'sas.XXX', 'fc.XXX', and 'iqn.XXX' WWN
>> which would attach to the respective transport class, and any other
>> WWN (which would be the default) would be getting the standard
>> emulation without any transport class attached.
>
> I'm open to merging the tcm_loop patches #1-#6 as-is for the sas
> transport pieces, or wait until you've done a large split based on
> transport class types.
>
> It's really your call how the initial merge should look.
>
Probably leave out the transport class stuff for now; I kinda like
the idea of having all types of transport classes available for
tcm_loop.
But this is actually not related to the rest of the patchset, so
you can skip those for the time being.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/8] tcm_loop updates
2015-07-07 5:50 ` Hannes Reinecke
@ 2015-07-07 6:26 ` Nicholas A. Bellinger
2015-07-07 6:29 ` Hannes Reinecke
0 siblings, 1 reply; 24+ messages in thread
From: Nicholas A. Bellinger @ 2015-07-07 6:26 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Christoph Hellwig, Nic Bellinger, target-devel, linux-scsi,
Ewan Milne
On Tue, 2015-07-07 at 07:50 +0200, Hannes Reinecke wrote:
> On 07/07/2015 02:25 AM, Nicholas A. Bellinger wrote:
> > On Tue, 2015-06-23 at 11:05 +0200, Hannes Reinecke wrote:
> >> On 06/23/2015 10:29 AM, Nicholas A. Bellinger wrote:
<SNIP>
> >>> How different do you expect sas, fc, and iscsi transports to be..?
> >>>
> >>> Do you think this would this be better served by a simple tcm_loop LLD
> >>> specific API for different multipath transports..?
> >>>
> >> Actually, I would split off the various transport functions into
> >> separate files (tcm_loop_sas, tcm_loop_fc, etc), but keep a common
> >> tcm_loop module.
> >> We can even make transport classes optional by adding an explicit
> >> 'sas.XXX' prefix scanning when creating the device similar to what
> >> we do with the 'fc.XXX' prefix already.
> >> With that we would have a 'sas.XXX', 'fc.XXX', and 'iqn.XXX' WWN
> >> which would attach to the respective transport class, and any other
> >> WWN (which would be the default) would be getting the standard
> >> emulation without any transport class attached.
> >
> > I'm open to merging the tcm_loop patches #1-#6 as-is for the sas
> > transport pieces, or wait until you've done a large split based on
> > transport class types.
> >
> > It's really your call how the initial merge should look.
> >
> Probably leave out the transport class stuff for now; I kinda like
> the idea of having all types of transport classes available for
> tcm_loop.
> But this is actually not related to the rest of the patchset, so
> you can skip those for the time being.
>
Just to confirm, applying patch #3-#6, and #8 to for-next now.
Skipping #7 for the moment, given host side expectations short of being
configurable as noted by HCH.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/8] tcm_loop updates
2015-07-07 6:26 ` Nicholas A. Bellinger
@ 2015-07-07 6:29 ` Hannes Reinecke
2015-07-07 6:42 ` Nicholas A. Bellinger
0 siblings, 1 reply; 24+ messages in thread
From: Hannes Reinecke @ 2015-07-07 6:29 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Christoph Hellwig, Nic Bellinger, target-devel, linux-scsi,
Ewan Milne
On 07/07/2015 08:26 AM, Nicholas A. Bellinger wrote:
> On Tue, 2015-07-07 at 07:50 +0200, Hannes Reinecke wrote:
>> On 07/07/2015 02:25 AM, Nicholas A. Bellinger wrote:
>>> On Tue, 2015-06-23 at 11:05 +0200, Hannes Reinecke wrote:
>>>> On 06/23/2015 10:29 AM, Nicholas A. Bellinger wrote:
>
> <SNIP>
>
>>>>> How different do you expect sas, fc, and iscsi transports to be..?
>>>>>
>>>>> Do you think this would this be better served by a simple tcm_loop LLD
>>>>> specific API for different multipath transports..?
>>>>>
>>>> Actually, I would split off the various transport functions into
>>>> separate files (tcm_loop_sas, tcm_loop_fc, etc), but keep a common
>>>> tcm_loop module.
>>>> We can even make transport classes optional by adding an explicit
>>>> 'sas.XXX' prefix scanning when creating the device similar to what
>>>> we do with the 'fc.XXX' prefix already.
>>>> With that we would have a 'sas.XXX', 'fc.XXX', and 'iqn.XXX' WWN
>>>> which would attach to the respective transport class, and any other
>>>> WWN (which would be the default) would be getting the standard
>>>> emulation without any transport class attached.
>>>
>>> I'm open to merging the tcm_loop patches #1-#6 as-is for the sas
>>> transport pieces, or wait until you've done a large split based on
>>> transport class types.
>>>
>>> It's really your call how the initial merge should look.
>>>
>> Probably leave out the transport class stuff for now; I kinda like
>> the idea of having all types of transport classes available for
>> tcm_loop.
>> But this is actually not related to the rest of the patchset, so
>> you can skip those for the time being.
>>
>
> Just to confirm, applying patch #3-#6, and #8 to for-next now.
>
> Skipping #7 for the moment, given host side expectations short of being
> configurable as noted by HCH.
>
Precisely. Thank you.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/8] tcm_loop updates
2015-07-07 6:29 ` Hannes Reinecke
@ 2015-07-07 6:42 ` Nicholas A. Bellinger
0 siblings, 0 replies; 24+ messages in thread
From: Nicholas A. Bellinger @ 2015-07-07 6:42 UTC (permalink / raw)
To: Hannes Reinecke
Cc: Christoph Hellwig, Nic Bellinger, target-devel, linux-scsi,
Ewan Milne
On Tue, 2015-07-07 at 08:29 +0200, Hannes Reinecke wrote:
> On 07/07/2015 08:26 AM, Nicholas A. Bellinger wrote:
> > On Tue, 2015-07-07 at 07:50 +0200, Hannes Reinecke wrote:
> >> On 07/07/2015 02:25 AM, Nicholas A. Bellinger wrote:
> >>> On Tue, 2015-06-23 at 11:05 +0200, Hannes Reinecke wrote:
> >>>> On 06/23/2015 10:29 AM, Nicholas A. Bellinger wrote:
> >
> > <SNIP>
> >
> >>>>> How different do you expect sas, fc, and iscsi transports to be..?
> >>>>>
> >>>>> Do you think this would this be better served by a simple tcm_loop LLD
> >>>>> specific API for different multipath transports..?
> >>>>>
> >>>> Actually, I would split off the various transport functions into
> >>>> separate files (tcm_loop_sas, tcm_loop_fc, etc), but keep a common
> >>>> tcm_loop module.
> >>>> We can even make transport classes optional by adding an explicit
> >>>> 'sas.XXX' prefix scanning when creating the device similar to what
> >>>> we do with the 'fc.XXX' prefix already.
> >>>> With that we would have a 'sas.XXX', 'fc.XXX', and 'iqn.XXX' WWN
> >>>> which would attach to the respective transport class, and any other
> >>>> WWN (which would be the default) would be getting the standard
> >>>> emulation without any transport class attached.
> >>>
> >>> I'm open to merging the tcm_loop patches #1-#6 as-is for the sas
> >>> transport pieces, or wait until you've done a large split based on
> >>> transport class types.
> >>>
> >>> It's really your call how the initial merge should look.
> >>>
> >> Probably leave out the transport class stuff for now; I kinda like
> >> the idea of having all types of transport classes available for
> >> tcm_loop.
> >> But this is actually not related to the rest of the patchset, so
> >> you can skip those for the time being.
> >>
> >
> > Just to confirm, applying patch #3-#6, and #8 to for-next now.
> >
> > Skipping #7 for the moment, given host side expectations short of being
> > configurable as noted by HCH.
> >
> Precisely. Thank you.
>
Whoops, forgot that logic for #6 was already applied to v4.2-rc1, and
HCH had some objections to patch #8.
Also, #5 does depend on the sas transport class support.
So just applying #3-#4 for now..
^ permalink raw reply [flat|nested] 24+ messages in thread