[RFC-v3 2/9] iscsi-target: Add iscsit_transport API template
From: Nicholas Bellinger
Add basic struct iscsit_transport API template to allow iscsi-target for
running with external transport modules using existing iscsi_target_core.h
code.
For all external modules, this calls try_module_get() and module_put()
to obtain + release an external iscsit_transport module reference count.
Also include the iscsi-target symbols necessary in iscsi_transport.h to
allow external transport modules to function.
v3 changes:
- Add iscsit_build_reject export for ISTATE_SEND_REJECT usage
v2 changes:
- Drop unnecessary export of iscsit_get_transport + iscsit_put_transport
(roland)
- Add ->iscsit_queue_data_in() to remove extra context switch on RDMA_WRITE
- Add ->iscsit_queue_status() to remove extra context switch on IB_SEND status
- Add ->iscsit_get_dataout() to remove extra context switch on RDMA_READ
- Drop ->iscsit_free_cmd()
- Drop ->iscsit_unmap_cmd()
- Rename iscsit_create_transport() -> iscsit_register_transport() (andy)
- Rename iscsit_destroy_transport() -> iscsit_unregister_transport() (andy)
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/Makefile |3 +-
drivers/target/iscsi/iscsi_target_transport.c | 55
include/target/iscsi/iscsi_transport.h| 83 +
3 files changed, 140 insertions(+), 1 deletions(-)
create mode 100644 drivers/target/iscsi/iscsi_target_transport.c
create mode 100644 include/target/iscsi/iscsi_transport.h
diff --git a/drivers/target/iscsi/Makefile b/drivers/target/iscsi/Makefile
index 5b9a2cf..13a9240 100644
--- a/drivers/target/iscsi/Makefile
+++ b/drivers/target/iscsi/Makefile
@@ -15,6 +15,7 @@ iscsi_target_mod-y += iscsi_target_parameters.o \
iscsi_target_util.o \
iscsi_target.o \
iscsi_target_configfs.o \
- iscsi_target_stat.o
+ iscsi_target_stat.o \
+ iscsi_target_transport.o
obj-$(CONFIG_ISCSI_TARGET) += iscsi_target_mod.o
diff --git a/drivers/target/iscsi/iscsi_target_transport.c
b/drivers/target/iscsi/iscsi_target_transport.c
new file mode 100644
index 000..882728f
--- /dev/null
+++ b/drivers/target/iscsi/iscsi_target_transport.c
@@ -0,0 +1,55 @@
+#include
+#include
+#include
+
+static LIST_HEAD(g_transport_list);
+static DEFINE_MUTEX(transport_mutex);
+
+struct iscsit_transport *iscsit_get_transport(int type)
+{
+ struct iscsit_transport *t;
+
+ mutex_lock(&transport_mutex);
+ list_for_each_entry(t, &g_transport_list, t_node) {
+ if (t->transport_type == type) {
+ if (t->owner && !try_module_get(t->owner)) {
+ t = NULL;
+ }
+ mutex_unlock(&transport_mutex);
+ return t;
+ }
+ }
+ mutex_unlock(&transport_mutex);
+
+ return NULL;
+}
+
+void iscsit_put_transport(struct iscsit_transport *t)
+{
+ if (t->owner)
+ module_put(t->owner);
+}
+
+int iscsit_register_transport(struct iscsit_transport *t)
+{
+ INIT_LIST_HEAD(&t->t_node);
+
+ mutex_lock(&transport_mutex);
+ list_add_tail(&t->t_node, &g_transport_list);
+ mutex_unlock(&transport_mutex);
+
+ pr_debug("Registered iSCSI transport: %s\n", t->name);
+
+ return 0;
+}
+EXPORT_SYMBOL(iscsit_register_transport);
+
+void iscsit_unregister_transport(struct iscsit_transport *t)
+{
+ mutex_lock(&transport_mutex);
+ list_del(&t->t_node);
+ mutex_unlock(&transport_mutex);
+
+ pr_debug("Unregistered iSCSI transport: %s\n", t->name);
+}
+EXPORT_SYMBOL(iscsit_unregister_transport);
diff --git a/include/target/iscsi/iscsi_transport.h
b/include/target/iscsi/iscsi_transport.h
new file mode 100644
index 000..23a87d0
--- /dev/null
+++ b/include/target/iscsi/iscsi_transport.h
@@ -0,0 +1,83 @@
+#include
+#include
+#include "../../../drivers/target/iscsi/iscsi_target_core.h"
+
+struct iscsit_transport {
+#define ISCSIT_TRANSPORT_NAME 16
+ char name[ISCSIT_TRANSPORT_NAME];
+ int transport_type;
+ struct module *owner;
+ struct list_head t_node;
+ int (*iscsit_setup_np)(struct iscsi_np *, struct
__kernel_sockaddr_storage *);
+ int (*iscsit_accept_np)(struct iscsi_np *, struct iscsi_conn *);
+ void (*iscsit_free_np)(struct iscsi_np *);
+ void (*iscsit_free_conn)(struct iscsi_conn *);
+ struct iscsi_cmd *(*iscsit_alloc_cmd)(struct iscsi_conn *, gfp_t);
+ int (*iscsit_get_login_rx)(struct iscsi_conn *, struct iscsi_login *);
+ int (*iscsit_put_login_tx)(struct iscsi_conn *, struct iscsi_login *,
u32);
+ int (*iscsit_immediate_queue)(struct iscsi_conn *, struct iscsi_cmd *,
int);
+ int (*iscsit_response_queue)(struct iscsi_conn *, struct iscsi_cmd *,
int);
+ int (*iscsit_get_da
[RFC-v3 5/9] iscsi-target: Add per transport iscsi_cmd alloc/free
From: Nicholas Bellinger
This patch converts struct iscsi_cmd memory allocation + free to use
->iscsit_alloc_cmd() iscsit_transport API caller, and export
iscsit_allocate_cmd() symbols
Also add iscsi_cmd->release_cmd() to be used seperately from
iscsit_transport for connection/session shutdown.
v2 changes:
- Remove unnecessary checks in iscsit_alloc_cmd (asias)
- Drop iscsit_transport->iscsit_free_cmd() usage
- Drop iscsit_transport->iscsit_unmap_cmd() usage
- Add iscsi_cmd->release_cmd()
- Convert lio_release_cmd() to use iscsi_cmd->release_cmd()
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/iscsi_target.c |1 +
drivers/target/iscsi/iscsi_target_configfs.c |3 ++-
drivers/target/iscsi/iscsi_target_core.h |1 +
drivers/target/iscsi/iscsi_target_util.c | 25 +
drivers/target/iscsi/iscsi_target_util.h |1 +
5 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
index 8203bf3..b01a10e 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -489,6 +489,7 @@ static struct iscsit_transport iscsi_target_transport = {
.iscsit_setup_np= iscsit_setup_np,
.iscsit_accept_np = iscsit_accept_np,
.iscsit_free_np = iscsit_free_np,
+ .iscsit_alloc_cmd = iscsit_alloc_cmd,
.iscsit_get_login_rx= iscsit_get_login_rx,
.iscsit_put_login_tx= iscsit_put_login_tx,
};
diff --git a/drivers/target/iscsi/iscsi_target_configfs.c
b/drivers/target/iscsi/iscsi_target_configfs.c
index 78d75c8..c78b824 100644
--- a/drivers/target/iscsi/iscsi_target_configfs.c
+++ b/drivers/target/iscsi/iscsi_target_configfs.c
@@ -1700,7 +1700,8 @@ static void lio_release_cmd(struct se_cmd *se_cmd)
{
struct iscsi_cmd *cmd = container_of(se_cmd, struct iscsi_cmd, se_cmd);
- iscsit_release_cmd(cmd);
+ pr_debug("Entering lio_release_cmd for se_cmd: %p\n", se_cmd);
+ cmd->release_cmd(cmd);
}
/* End functions for target_core_fabric_ops */
diff --git a/drivers/target/iscsi/iscsi_target_core.h
b/drivers/target/iscsi/iscsi_target_core.h
index 53400b0..60ec4b9 100644
--- a/drivers/target/iscsi/iscsi_target_core.h
+++ b/drivers/target/iscsi/iscsi_target_core.h
@@ -485,6 +485,7 @@ struct iscsi_cmd {
u32 first_data_sg_off;
u32 kmapped_nents;
sense_reason_t sense_reason;
+ void (*release_cmd)(struct iscsi_cmd *);
} cacheline_aligned;
struct iscsi_tmr_req {
diff --git a/drivers/target/iscsi/iscsi_target_util.c
b/drivers/target/iscsi/iscsi_target_util.c
index 4cf1e7f..0b73f90 100644
--- a/drivers/target/iscsi/iscsi_target_util.c
+++ b/drivers/target/iscsi/iscsi_target_util.c
@@ -149,6 +149,18 @@ void iscsit_free_r2ts_from_list(struct iscsi_cmd *cmd)
spin_unlock_bh(&cmd->r2t_lock);
}
+struct iscsi_cmd *iscsit_alloc_cmd(struct iscsi_conn *conn, gfp_t gfp_mask)
+{
+ struct iscsi_cmd *cmd;
+
+ cmd = kmem_cache_zalloc(lio_cmd_cache, gfp_mask);
+ if (!cmd)
+ return NULL;
+
+ cmd->release_cmd = &iscsit_release_cmd;
+ return cmd;
+}
+
/*
* May be called from software interrupt (timer) context for allocating
* iSCSI NopINs.
@@ -157,13 +169,12 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn
*conn, gfp_t gfp_mask)
{
struct iscsi_cmd *cmd;
- cmd = kmem_cache_zalloc(lio_cmd_cache, gfp_mask);
+ cmd = conn->conn_transport->iscsit_alloc_cmd(conn, gfp_mask);
if (!cmd) {
pr_err("Unable to allocate memory for struct iscsi_cmd.\n");
return NULL;
}
-
- cmd->conn = conn;
+ cmd->conn = conn;
INIT_LIST_HEAD(&cmd->i_conn_node);
INIT_LIST_HEAD(&cmd->datain_list);
INIT_LIST_HEAD(&cmd->cmd_r2t_list);
@@ -176,6 +187,7 @@ struct iscsi_cmd *iscsit_allocate_cmd(struct iscsi_conn
*conn, gfp_t gfp_mask)
return cmd;
}
+EXPORT_SYMBOL(iscsit_allocate_cmd);
struct iscsi_seq *iscsit_get_seq_holder_for_datain(
struct iscsi_cmd *cmd,
@@ -690,6 +702,11 @@ void iscsit_free_cmd(struct iscsi_cmd *cmd)
*/
switch (cmd->iscsi_opcode) {
case ISCSI_OP_SCSI_CMD:
+ if (cmd->data_direction == DMA_TO_DEVICE)
+ iscsit_stop_dataout_timer(cmd);
+ /*
+* Fallthrough
+*/
case ISCSI_OP_SCSI_TMFUNC:
transport_generic_free_cmd(&cmd->se_cmd, 1);
break;
@@ -705,7 +722,7 @@ void iscsit_free_cmd(struct iscsi_cmd *cmd)
}
/* Fall-through */
default:
- iscsit_release_cmd(cmd);
+ cmd->release_cmd(cmd);
break;
}
}
diff --git a/drivers/target/iscsi/iscsi_target_util.h
b/drivers/target/iscsi/iscsi_tar
[RFC-v3 7/9] iscsi-target: Refactor TX queue logic + export response PDU creation
From: Nicholas Bellinger
This patch refactors TX immediate + response queue handling to use
the new iscsit_transport API callers, and exports the necessary
traditional iscsi PDU response creation functions for iser-target
to utilize.
This includes:
- Add iscsit_build_datain_pdu() for DATAIN PDU init + convert
iscsit_build_datain_pdu()
- Add iscsit_build_logout_rsp() for LOGOUT_RSP PDU init + convert
iscsit_send_logout()
- Add iscsit_build_nopin_rsp() for NOPIN_RSP PDU init + convert
iscsit_send_nopin()
- Add iscsit_build_rsp_pdu() for SCSI_RSP PDU init + convert
iscsit_send_response()
- Add iscsit_build_task_mgt_rsp for TM_RSP PDU init + convert
iscsit_send_task_mgt_rsp()
- Refactor immediate queue state switch into iscsit_immediate_queue()
- Convert handle_immediate_queue() to use iscsit_transport caller
- Refactor response queue state switch into iscsit_response_queue()
- Convert handle_response_queue to use iscsit_transport caller
- Export iscsit_logout_post_handler(), iscsit_increment_maxcmdsn()
and iscsit_tmr_post_handler() for external transport module usage
v3 changes:
- Add iscsit_build_reject for REJECT PDU init + convert
iscsit_send_reject()
v2 changes:
- Add iscsit_queue_rsp() for iscsit_transport->iscsit_queue_data_in()
and iscsit_transport->iscsit_queue_status()
- Update lio_queue_data_in() to use ->iscsit_queue_data_in()
- Update lio_queue_status() to use ->iscsit_queue_status()
- Use mutex_trylock() in iscsit_increment_maxcmdsn()
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/iscsi_target.c | 661 ++
drivers/target/iscsi/iscsi_target_configfs.c |7 +-
drivers/target/iscsi/iscsi_target_device.c |7 +-
drivers/target/iscsi/iscsi_target_tmr.c |1 +
4 files changed, 374 insertions(+), 302 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
index 19d4e08..3948aa1 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -70,8 +70,7 @@ struct kmem_cache *lio_ooo_cache;
struct kmem_cache *lio_r2t_cache;
static int iscsit_handle_immediate_data(struct iscsi_cmd *,
- unsigned char *buf, u32);
-static int iscsit_logout_post_handler(struct iscsi_cmd *, struct iscsi_conn *);
+ struct iscsi_scsi_req *, u32);
struct iscsi_tiqn *iscsit_get_tiqn_for_login(unsigned char *buf)
{
@@ -482,6 +481,15 @@ int iscsit_del_np(struct iscsi_np *np)
return 0;
}
+static int iscsit_immediate_queue(struct iscsi_conn *, struct iscsi_cmd *,
int);
+static int iscsit_response_queue(struct iscsi_conn *, struct iscsi_cmd *, int);
+
+static int iscsit_queue_rsp(struct iscsi_conn *conn, struct iscsi_cmd *cmd)
+{
+ iscsit_add_cmd_to_response_queue(cmd, cmd->conn, cmd->i_state);
+ return 0;
+}
+
static struct iscsit_transport iscsi_target_transport = {
.name = "iSCSI/TCP",
.transport_type = ISCSI_TCP,
@@ -493,6 +501,10 @@ static struct iscsit_transport iscsi_target_transport = {
.iscsit_get_login_rx= iscsit_get_login_rx,
.iscsit_put_login_tx= iscsit_put_login_tx,
.iscsit_get_dataout = iscsit_build_r2ts_for_cmd,
+ .iscsit_immediate_queue = iscsit_immediate_queue,
+ .iscsit_response_queue = iscsit_response_queue,
+ .iscsit_queue_data_in = iscsit_queue_rsp,
+ .iscsit_queue_status= iscsit_queue_rsp,
};
static int __init iscsi_target_init_module(void)
@@ -651,14 +663,6 @@ static int iscsit_add_reject(
iscsit_add_cmd_to_response_queue(cmd, conn, cmd->i_state);
ret = wait_for_completion_interruptible(&cmd->reject_comp);
- /*
-* Perform the kref_put now if se_cmd has been setup by
-* iscsit_setup_scsi_cmd()
-*/
- if (cmd->se_cmd.se_tfo != NULL) {
- pr_debug("iscsi reject: calling target_put_sess_cmd >>\n");
- target_put_sess_cmd(conn->sess->se_sess, &cmd->se_cmd);
- }
if (ret != 0)
return -1;
@@ -2536,18 +2540,60 @@ static void iscsit_tx_thread_wait_for_tcp(struct
iscsi_conn *conn)
}
}
-static int iscsit_send_data_in(
- struct iscsi_cmd *cmd,
- struct iscsi_conn *conn)
+static void
+iscsit_build_datain_pdu(struct iscsi_cmd *cmd, struct iscsi_conn *conn,
+ struct iscsi_datain *datain, struct iscsi_data_rsp *hdr,
+ bool set_statsn)
{
- int iov_ret = 0, set_statsn = 0;
- u32 iov_count = 0, tx_size = 0;
+ hdr->opcode = ISCSI_OP_SCSI_DATA_IN;
+ hdr->flags = datain->flags;
+ if (hdr->flags & ISCSI_FLAG_DATA_STATUS) {
+ if (cmd->se_cmd.se_cmd_flags & SCF_OVERFLOW_BIT) {
+ hdr->flags |= ISCSI_FLAG_DATA_OVERFLOW;
+ hdr->residual_count =
cpu_to_be32(cmd->se_cmd.residual_count);
+ } e
[RFC-v3 8/9] iscsi-target: Add iser network portal attribute
From: Nicholas Bellinger
This patch adds a new network portal attribute for iser, that lives
under existing iscsi-target configfs layout at:
/sys/kernel/config/target/iscsi/$TARGETNAME/$TPGT/np/$PORTAL/iser
When lio_target_np_store_iser() is enabled, iscsit_tpg_add_network_portal()
will attempt to start an rdma_cma network portal for iser-target, only if
the external ib_isert module transport has been loaded.
When disabled, iscsit_tpg_del_network_portal() will cease iser login service
on the network portal, and release any external ib_isert module reference.
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/iscsi_target_configfs.c | 75 ++
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target_configfs.c
b/drivers/target/iscsi/iscsi_target_configfs.c
index 2704daf..9763fec 100644
--- a/drivers/target/iscsi/iscsi_target_configfs.c
+++ b/drivers/target/iscsi/iscsi_target_configfs.c
@@ -125,8 +125,83 @@ out:
TF_NP_BASE_ATTR(lio_target, sctp, S_IRUGO | S_IWUSR);
+static ssize_t lio_target_np_show_iser(
+ struct se_tpg_np *se_tpg_np,
+ char *page)
+{
+ struct iscsi_tpg_np *tpg_np = container_of(se_tpg_np,
+ struct iscsi_tpg_np, se_tpg_np);
+ struct iscsi_tpg_np *tpg_np_iser;
+ ssize_t rb;
+
+ tpg_np_iser = iscsit_tpg_locate_child_np(tpg_np, ISCSI_INFINIBAND);
+ if (tpg_np_iser)
+ rb = sprintf(page, "1\n");
+ else
+ rb = sprintf(page, "0\n");
+
+ return rb;
+}
+
+static ssize_t lio_target_np_store_iser(
+ struct se_tpg_np *se_tpg_np,
+ const char *page,
+ size_t count)
+{
+ struct iscsi_np *np;
+ struct iscsi_portal_group *tpg;
+ struct iscsi_tpg_np *tpg_np = container_of(se_tpg_np,
+ struct iscsi_tpg_np, se_tpg_np);
+ struct iscsi_tpg_np *tpg_np_iser = NULL;
+ char *endptr;
+ u32 op;
+ int rc;
+
+ op = simple_strtoul(page, &endptr, 0);
+ if ((op != 1) && (op != 0)) {
+ pr_err("Illegal value for tpg_enable: %u\n", op);
+ return -EINVAL;
+ }
+ np = tpg_np->tpg_np;
+ if (!np) {
+ pr_err("Unable to locate struct iscsi_np from"
+ " struct iscsi_tpg_np\n");
+ return -EINVAL;
+ }
+
+ tpg = tpg_np->tpg;
+ if (iscsit_get_tpg(tpg) < 0)
+ return -EINVAL;
+
+ if (op) {
+ tpg_np_iser = iscsit_tpg_add_network_portal(tpg,
&np->np_sockaddr,
+ np->np_ip, tpg_np, ISCSI_INFINIBAND);
+ if (!tpg_np_iser || IS_ERR(tpg_np_iser))
+ goto out;
+ } else {
+ tpg_np_iser = iscsit_tpg_locate_child_np(tpg_np,
ISCSI_INFINIBAND);
+ if (!tpg_np_iser)
+ goto out;
+
+ rc = iscsit_tpg_del_network_portal(tpg, tpg_np_iser);
+ if (rc < 0)
+ goto out;
+ }
+
+ printk("lio_target_np_store_iser() done, op: %d\n", op);
+
+ iscsit_put_tpg(tpg);
+ return count;
+out:
+ iscsit_put_tpg(tpg);
+ return -EINVAL;
+}
+
+TF_NP_BASE_ATTR(lio_target, iser, S_IRUGO | S_IWUSR);
+
static struct configfs_attribute *lio_target_portal_attrs[] = {
&lio_target_np_sctp.attr,
+ &lio_target_np_iser.attr,
NULL,
};
--
1.7.2.5
--
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
[RFC-v3 0/9] Add support for iSCSI Extensions for RDMA (ISER) target mode
From: Nicholas Bellinger This series is the third RFC for iSCSI Extensions for RDMA (ISER) target mode support planned for an future v3.10 merge. This series refactors existing traditional iscsi-target mode logic in order for external ib_isert.ko module code to function with areas common to traditional TCP socket based iSCSI and RDMA verbs based ISER operation. This includes a basic iscsit_transport API that allows different transports to reside under the existing iscsi-target configfs control plane, using an pre-defined network portal attribute to enable a rdma_cm listener on top of existing ipoib portals. At this point the code is functional and pushing sustained RDMA_WRITE + RDMA_READ traffic using open-iscsi on top of multiple iser network portals + multiple IB HCA ports + multiple LUNs. Thus far we're using Mellanox IB HCAs for initial development, and will be verfiying with RCoE capable NICs as well in the near future. This RFC-v3 code is available in git against v3.9-rc3 here: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git iser_target-rfc-v3 The changes included since RFC-v2 include: - Convert to use per isert_cq_desc->cq_[rx,tx]_work + drop tasklets (Or + nab) - Move IB_EVENT_QP_LAST_WQE_REACHED warn into correct isert_qp_event_callback (Or) - Drop unnecessary IB_ACCESS_REMOTE_* access flag usage in isert_create_device_ib_res (Or) - Add common isert_init_send_wr(), and convert isert_put_* calls (Or) - Move to verbs+core logic to single ib_isert.[c,h] (Or + nab) - Add kmem_cache isert_cmd_cache usage for descriptor allocation (nab) - Move common ib_post_send() logic used by isert_put_*() to isert_post_response() (nab) - Add isert_put_reject call in isert_response_queue() for posting ISCSI_REJECT response. (nab) - Add ISTATE_SEND_REJECT checking in isert_do_control_comp. (nab) - Add extra target_put_sess_cmd call in iscsit_add_reject_from_cmd after completion - Add iscsit_build_reject for REJECT PDU init + convert iscsit_send_reject() - Add iscsi_post_login_start_timers FIXME for ISER Many thanks again to Or Gerlitz from Mellanox for v2 review feedback! With the per isert_cq_desc->cq_[rx,tx]_work cmwq dispatch now in place, process context switch overhead is reduced to each cq callback, instead of per each ib_poll_cq ib_wc descriptor as with tasklets in RFC-v2 code. This allows RFC-v3 to reach within ~%5 of single-lun NULLIO small block IOPs performance parity vs. existing STGT iser code, at almost 1/10 the number of total context switches. As before, review patches are broken down into: Patch #1 adds the export of target_get_sess_cmd to be used by iscsi-target Patch #2 -> #4 include iscsi-target API template, conversion of iscsi/tcp login path to use API template, plus add iser RFC parameter keys. Patch #5 -> #6 allow external iscsi_cmd descriptor allocation / free, and refactoring of RX side PDU request handling to allow incoming PDU logic to be called by external ib_isert workqueue process context. Patch #7 allows iscsi-target to use per transport API template immediate / response callbacks in the per-connection TX thread completion path, and refactoring of response PDU creation for export to external ib_isert code. Patch #8 adds the pre-defined iser network portal attribute under the existing iscsi-target configfs tree. Patch #9 -> #12 is the external ib_isert.ko module code seperated into individual commits for review. Note that I'll be dropping #1 -> #8 changes into target-pending/for-next shortly, and planning to do the same with ib_isert code soon unless there is an objection from Roland. Please review.. Thank you! --nab Nicholas Bellinger (9): target: Add export of target_get_sess_cmd symbol iscsi-target: Add iscsit_transport API template iscsi-target: Initial traditional TCP conversion to iscsit_transport iscsi-target: Add iser-target parameter keys + setup during login iscsi-target: Add per transport iscsi_cmd alloc/free iscsi-target: Refactor RX PDU logic + export request PDU handling iscsi-target: Refactor TX queue logic + export response PDU creation iscsi-target: Add iser network portal attribute iser-target: Add iSCSI Extensions for RDMA (iSER) target driver drivers/infiniband/Kconfig |1 + drivers/infiniband/Makefile|1 + drivers/infiniband/ulp/isert/Kconfig |6 + drivers/infiniband/ulp/isert/Makefile |2 + drivers/infiniband/ulp/isert/ib_isert.c| 2270 drivers/infiniband/ulp/isert/ib_isert.h| 142 ++ drivers/infiniband/ulp/isert/isert_proto.h | 47 + drivers/target/iscsi/Makefile |3 +- drivers/target/iscsi/iscsi_target.c| 1169 - drivers/target/iscsi/iscsi_target.h|3 +- drivers/target/iscsi/iscsi_target_configfs.c | 94 +- drivers/target/iscsi/iscsi_target_core.h | 26 +-
[RFC-v3 6/9] iscsi-target: Refactor RX PDU logic + export request PDU handling
From: Nicholas Bellinger
This patch refactors existing traditional iscsi RX side PDU handling
to use iscsit_transport, and exports the necessary logic for external
transport modules.
This includes:
- Refactor iscsit_handle_scsi_cmd() into PDU setup / processing
- Add updated iscsit_handle_scsi_cmd() for tradtional iscsi code
- Add iscsit_set_unsoliticed_dataout() wrapper
- Refactor iscsit_handle_data_out() into PDU check / processing
- Add updated iscsit_handle_data_out() for tradtional iscsi code
- Add iscsit_handle_nop_out() + iscsit_handle_task_mgt_cmd() to
accept pre-allocated struct iscsi_cmd
- Add iscsit_build_r2ts_for_cmd() caller for iscsi_target_transport
to handle ISTATE_SEND_R2T for TX immediate queue
- Refactor main traditional iscsi iscsi_target_rx_thread() PDU switch
into iscsi_target_rx_opcode() using iscsit_allocate_cmd()
- Turn iscsi_target_rx_thread() process context into NOP for
ib_isert side work-queue.
v3 changes:
- Add extra target_put_sess_cmd call in iscsit_add_reject_from_cmd
after completion
v2 changes:
- Disable iscsit_ack_from_expstatsn() usage for RDMAExtentions=Yes
- Disable iscsit_allocate_datain_req() usage for RDMAExtentions=Yes
- Add target_get_sess_cmd() reference counting to
iscsit_setup_scsi_cmd()
- Add TFO->lio_check_stop_free() fabric API caller
- Add export of iscsit_stop_dataout_timer() symbol
- Add iscsit_build_r2ts_for_cmd() for iscsit_transport->iscsit_get_dataout()
- Convert existing usage of iscsit_build_r2ts_for_cmd() to
->iscsit_get_dataout()
- Drop RDMAExtentions=Yes specific check in iscsit_build_r2ts_for_cmd()
- Fix RDMAExtentions -> RDMAExtensions typo (andy)
- Pass correct dump_payload value into iscsit_get_immediate_data()
for iscsit_handle_scsi_cmd()
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/iscsi_target.c | 486 --
drivers/target/iscsi/iscsi_target.h |3 +-
drivers/target/iscsi/iscsi_target_configfs.c |9 +-
drivers/target/iscsi/iscsi_target_erl1.c | 13 +-
drivers/target/iscsi/iscsi_target_login.c|3 +-
drivers/target/iscsi/iscsi_target_nego.c | 15 -
drivers/target/iscsi/iscsi_target_tmr.c |3 +-
drivers/target/iscsi/iscsi_target_util.c |1 +
8 files changed, 331 insertions(+), 202 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
index b01a10e..19d4e08 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -492,6 +492,7 @@ static struct iscsit_transport iscsi_target_transport = {
.iscsit_alloc_cmd = iscsit_alloc_cmd,
.iscsit_get_login_rx= iscsit_get_login_rx,
.iscsit_put_login_tx= iscsit_put_login_tx,
+ .iscsit_get_dataout = iscsit_build_r2ts_for_cmd,
};
static int __init iscsi_target_init_module(void)
@@ -650,6 +651,14 @@ static int iscsit_add_reject(
iscsit_add_cmd_to_response_queue(cmd, conn, cmd->i_state);
ret = wait_for_completion_interruptible(&cmd->reject_comp);
+ /*
+* Perform the kref_put now if se_cmd has been setup by
+* iscsit_setup_scsi_cmd()
+*/
+ if (cmd->se_cmd.se_tfo != NULL) {
+ pr_debug("iscsi reject: calling target_put_sess_cmd >>\n");
+ target_put_sess_cmd(conn->sess->se_sess, &cmd->se_cmd);
+ }
if (ret != 0)
return -1;
@@ -698,11 +707,20 @@ int iscsit_add_reject_from_cmd(
iscsit_add_cmd_to_response_queue(cmd, conn, cmd->i_state);
ret = wait_for_completion_interruptible(&cmd->reject_comp);
+ /*
+* Perform the kref_put now if se_cmd has already been setup by
+* scsit_setup_scsi_cmd()
+*/
+ if (cmd->se_cmd.se_tfo != NULL) {
+ pr_debug("iscsi reject: calling target_put_sess_cmd >>\n");
+ target_put_sess_cmd(conn->sess->se_sess, &cmd->se_cmd);
+ }
if (ret != 0)
return -1;
return (!fail_conn) ? 0 : -1;
}
+EXPORT_SYMBOL(iscsit_add_reject_from_cmd);
/*
* Map some portion of the allocated scatterlist to an iovec, suitable for
@@ -761,6 +779,9 @@ static void iscsit_ack_from_expstatsn(struct iscsi_conn
*conn, u32 exp_statsn)
conn->exp_statsn = exp_statsn;
+ if (conn->sess->sess_ops->RDMAExtensions)
+ return;
+
spin_lock_bh(&conn->cmd_lock);
list_for_each_entry(cmd, &conn->conn_cmd_list, i_conn_node) {
spin_lock(&cmd->istate_lock);
@@ -793,12 +814,10 @@ static int iscsit_allocate_iovecs(struct iscsi_cmd *cmd)
return 0;
}
-static int iscsit_handle_scsi_cmd(
- struct iscsi_conn *conn,
- unsigned char *buf)
+int iscsit_setup_scsi_cmd(struct iscsi_conn *conn, struct iscsi_cmd *cmd,
+ unsigned char *buf)
{
- int data_direction, payload_length, cmdsn_ret = 0, immed_ret;
- struct iscsi_cmd *cmd = NULL;
+
[RFC-v3 4/9] iscsi-target: Add iser-target parameter keys + setup during login
From: Nicholas Bellinger
This patch adds RDMAExtensions, InitiatorRecvDataSegmentLength and
TargetRecvDataSegmentLength parameters keys necessary for iser-target
login to occur.
This includes setting the necessary parameters during login path
code within iscsi_login_zero_tsih_s2(), and currently PAGE_SIZE
aligning the target's advertised MRDSL for immediate data and
unsolicited data-out incoming payloads.
v3 changes:
- Add iscsi_post_login_start_timers FIXME for ISER
v2 changes:
- Fix RDMAExtentions -> RDMAExtensions typo (andy)
- Drop unnecessary '== true' conditional checks for type bool
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/iscsi_target_core.h | 10 +++
drivers/target/iscsi/iscsi_target_login.c | 77
drivers/target/iscsi/iscsi_target_parameters.c | 75 +--
drivers/target/iscsi/iscsi_target_parameters.h | 16 +-
4 files changed, 161 insertions(+), 17 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target_core.h
b/drivers/target/iscsi/iscsi_target_core.h
index 2587677..53400b0 100644
--- a/drivers/target/iscsi/iscsi_target_core.h
+++ b/drivers/target/iscsi/iscsi_target_core.h
@@ -244,6 +244,11 @@ struct iscsi_conn_ops {
u8 IFMarker; /* [0,1] == [No,Yes] */
u32 OFMarkInt; /* [1..65535] */
u32 IFMarkInt; /* [1..65535] */
+ /*
+* iSER specific connection parameters
+*/
+ u32 InitiatorRecvDataSegmentLength; /* [512..2**24-1] */
+ u32 TargetRecvDataSegmentLength;/* [512..2**24-1] */
};
struct iscsi_sess_ops {
@@ -265,6 +270,10 @@ struct iscsi_sess_ops {
u8 DataSequenceInOrder;/* [0,1] == [No,Yes] */
u8 ErrorRecoveryLevel; /* [0..2] */
u8 SessionType;/* [0,1] == [Normal,Discovery]*/
+ /*
+* iSER specific session parameters
+*/
+ u8 RDMAExtensions; /* [0,1] == [No,Yes] */
};
struct iscsi_queue_req {
@@ -284,6 +293,7 @@ struct iscsi_data_count {
};
struct iscsi_param_list {
+ booliser;
struct list_headparam_list;
struct list_headextra_response_list;
};
diff --git a/drivers/target/iscsi/iscsi_target_login.c
b/drivers/target/iscsi/iscsi_target_login.c
index 57f9dea..24a9e69 100644
--- a/drivers/target/iscsi/iscsi_target_login.c
+++ b/drivers/target/iscsi/iscsi_target_login.c
@@ -340,6 +340,7 @@ static int iscsi_login_zero_tsih_s2(
struct iscsi_node_attrib *na;
struct iscsi_session *sess = conn->sess;
unsigned char buf[32];
+ bool iser = false;
sess->tpg = conn->tpg;
@@ -361,7 +362,10 @@ static int iscsi_login_zero_tsih_s2(
return -1;
}
- iscsi_set_keys_to_negotiate(0, conn->param_list);
+ if (conn->conn_transport->transport_type == ISCSI_INFINIBAND)
+ iser = true;
+
+ iscsi_set_keys_to_negotiate(conn->param_list, iser);
if (sess->sess_ops->SessionType)
return iscsi_set_keys_irrelevant_for_discovery(
@@ -399,6 +403,56 @@ static int iscsi_login_zero_tsih_s2(
if (iscsi_login_disable_FIM_keys(conn->param_list, conn) < 0)
return -1;
+ /*
+* Set RDMAExtensions=Yes by default for iSER enabled network portals
+*/
+ if (iser) {
+ struct iscsi_param *param;
+ unsigned long mrdsl, off;
+ int rc;
+
+ sprintf(buf, "RDMAExtensions=Yes");
+ if (iscsi_change_param_value(buf, conn->param_list, 0) < 0) {
+ iscsit_tx_login_rsp(conn, ISCSI_STATUS_CLS_TARGET_ERR,
+ ISCSI_LOGIN_STATUS_NO_RESOURCES);
+ return -1;
+ }
+ /*
+* Make MaxRecvDataSegmentLength PAGE_SIZE aligned for
+* Immediate Data + Unsolicitied Data-OUT if necessary..
+*/
+ param = iscsi_find_param_from_key("MaxRecvDataSegmentLength",
+ conn->param_list);
+ if (!param) {
+ iscsit_tx_login_rsp(conn, ISCSI_STATUS_CLS_TARGET_ERR,
+ ISCSI_LOGIN_STATUS_NO_RESOURCES);
+ return -1;
+ }
+ rc = strict_strtoul(param->value, 0, &mrdsl);
+ if (rc < 0) {
+ iscsit_tx_login_rsp(conn, ISCSI_STATUS_CLS_TARGET_ERR,
+ ISCSI_LOGIN_STATUS_NO_RESOURCES);
+ return -1;
+ }
+ off = mrdsl % PAGE_SIZE;
+ if (!off)
+ return 0;
+
+ if (mrdsl < PAGE_SIZE)
+ mrdsl = PAGE_SIZE;
+ else
+
[RFC-v3 3/9] iscsi-target: Initial traditional TCP conversion to iscsit_transport
From: Nicholas Bellinger
This patch performs the initial conversion of existing traditional iscsi
to use iscsit_transport API callers. This includes:
- iscsi-np cleanups for iscsit_transport_type
- Add iscsi-np transport calls w/ ->iscsit_setup_up() and ->iscsit_free_np()
- Convert login thread process context to use ->iscsit_accept_np() for
connections with pre-allocated struct iscsi_conn
- Convert existing socket accept code to iscsit_accept_np()
- Convert login RX/TX callers to use ->iscsit_get_login_rx() and
->iscsit_put_login_tx() to exchange request/response PDUs
- Convert existing socket login RX/TX calls into iscsit_get_login_rx()
and iscsit_put_login_tx()
- Change iscsit_close_connection() to invoke ->iscsit_free_conn() +
iscsit_put_transport() calls.
- Add iscsit_register_transport() + iscsit_unregister_transport() calls
to module init/exit
v2 changes:
- Update module init/exit to use register_transport() + unregister_transport()
Signed-off-by: Nicholas Bellinger
---
drivers/target/iscsi/iscsi_target.c| 35 ++-
drivers/target/iscsi/iscsi_target_core.h | 15 +-
drivers/target/iscsi/iscsi_target_login.c | 414
drivers/target/iscsi/iscsi_target_login.h |6 +
drivers/target/iscsi/iscsi_target_nego.c | 167 ++-
drivers/target/iscsi/iscsi_target_nego.h | 11 +-
drivers/target/iscsi/iscsi_target_parameters.c | 12 +-
drivers/target/iscsi/iscsi_target_tpg.c|6 +-
drivers/target/iscsi/iscsi_target_util.c | 27 +--
9 files changed, 378 insertions(+), 315 deletions(-)
diff --git a/drivers/target/iscsi/iscsi_target.c
b/drivers/target/iscsi/iscsi_target.c
index 7ea246a..8203bf3 100644
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -49,6 +49,8 @@
#include "iscsi_target_device.h"
#include "iscsi_target_stat.h"
+#include
+
static LIST_HEAD(g_tiqn_list);
static LIST_HEAD(g_np_list);
static DEFINE_SPINLOCK(tiqn_lock);
@@ -401,8 +403,7 @@ struct iscsi_np *iscsit_add_np(
spin_unlock_bh(&np_lock);
pr_debug("CORE[0] - Added Network Portal: %s:%hu on %s\n",
- np->np_ip, np->np_port, (np->np_network_transport == ISCSI_TCP)
?
- "TCP" : "SCTP");
+ np->np_ip, np->np_port, np->np_transport->name);
return np;
}
@@ -441,11 +442,10 @@ int iscsit_reset_np_thread(
return 0;
}
-static int iscsit_del_np_comm(struct iscsi_np *np)
+static void iscsit_free_np(struct iscsi_np *np)
{
if (np->np_socket)
sock_release(np->np_socket);
- return 0;
}
int iscsit_del_np(struct iscsi_np *np)
@@ -467,20 +467,32 @@ int iscsit_del_np(struct iscsi_np *np)
send_sig(SIGINT, np->np_thread, 1);
kthread_stop(np->np_thread);
}
- iscsit_del_np_comm(np);
+
+ np->np_transport->iscsit_free_np(np);
spin_lock_bh(&np_lock);
list_del(&np->np_list);
spin_unlock_bh(&np_lock);
pr_debug("CORE[0] - Removed Network Portal: %s:%hu on %s\n",
- np->np_ip, np->np_port, (np->np_network_transport == ISCSI_TCP)
?
- "TCP" : "SCTP");
+ np->np_ip, np->np_port, np->np_transport->name);
+ iscsit_put_transport(np->np_transport);
kfree(np);
return 0;
}
+static struct iscsit_transport iscsi_target_transport = {
+ .name = "iSCSI/TCP",
+ .transport_type = ISCSI_TCP,
+ .owner = NULL,
+ .iscsit_setup_np= iscsit_setup_np,
+ .iscsit_accept_np = iscsit_accept_np,
+ .iscsit_free_np = iscsit_free_np,
+ .iscsit_get_login_rx= iscsit_get_login_rx,
+ .iscsit_put_login_tx= iscsit_put_login_tx,
+};
+
static int __init iscsi_target_init_module(void)
{
int ret = 0;
@@ -557,6 +569,8 @@ static int __init iscsi_target_init_module(void)
goto ooo_out;
}
+ iscsit_register_transport(&iscsi_target_transport);
+
if (iscsit_load_discovery_tpg() < 0)
goto r2t_out;
@@ -587,6 +601,7 @@ static void __exit iscsi_target_cleanup_module(void)
iscsi_deallocate_thread_sets();
iscsi_thread_set_free();
iscsit_release_discovery_tpg();
+ iscsit_unregister_transport(&iscsi_target_transport);
kmem_cache_destroy(lio_cmd_cache);
kmem_cache_destroy(lio_qr_cache);
kmem_cache_destroy(lio_dr_cache);
@@ -4053,6 +4068,12 @@ int iscsit_close_connection(
if (conn->sock)
sock_release(conn->sock);
+
+ if (conn->conn_transport->iscsit_free_conn)
+ conn->conn_transport->iscsit_free_conn(conn);
+
+ iscsit_put_transport(conn->conn_transport);
+
conn->thread_set = NULL;
pr_debug("Moving to TARG_CONN_STATE_FREE.\n");
diff --git a/drivers/target/iscsi/iscsi_target_core.h
b/drivers/target/iscs
[RFC-v3 1/9] target: Add export of target_get_sess_cmd symbol
From: Nicholas Bellinger
Export target_get_sess_cmd() symbol so that it can be used by
iscsi-target.
Signed-off-by: Nicholas Bellinger
---
drivers/target/target_core_transport.c |4 ++--
include/target/target_core_fabric.h|2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index 493e9e5..f8388b4 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -65,7 +65,6 @@ static void transport_complete_task_attr(struct se_cmd *cmd);
static void transport_handle_queue_full(struct se_cmd *cmd,
struct se_device *dev);
static int transport_generic_get_mem(struct se_cmd *cmd);
-static int target_get_sess_cmd(struct se_session *, struct se_cmd *, bool);
static void transport_put_cmd(struct se_cmd *cmd);
static void target_complete_ok_work(struct work_struct *work);
@@ -2179,7 +2178,7 @@ EXPORT_SYMBOL(transport_generic_free_cmd);
* @se_cmd:command descriptor to add
* @ack_kref: Signal that fabric will perform an ack target_put_sess_cmd()
*/
-static int target_get_sess_cmd(struct se_session *se_sess, struct se_cmd
*se_cmd,
+int target_get_sess_cmd(struct se_session *se_sess, struct se_cmd *se_cmd,
bool ack_kref)
{
unsigned long flags;
@@ -2208,6 +2207,7 @@ out:
spin_unlock_irqrestore(&se_sess->sess_cmd_lock, flags);
return ret;
}
+EXPORT_SYMBOL(target_get_sess_cmd);
static void target_release_cmd_kref(struct kref *kref)
{
diff --git a/include/target/target_core_fabric.h
b/include/target/target_core_fabric.h
index aaa1ee6..ba3471b 100644
--- a/include/target/target_core_fabric.h
+++ b/include/target/target_core_fabric.h
@@ -120,7 +120,7 @@ booltransport_wait_for_tasks(struct se_cmd *);
inttransport_check_aborted_status(struct se_cmd *, int);
inttransport_send_check_condition_and_sense(struct se_cmd *,
sense_reason_t, int);
-
+inttarget_get_sess_cmd(struct se_session *, struct se_cmd *, bool);
inttarget_put_sess_cmd(struct se_session *, struct se_cmd *);
void target_sess_cmd_list_set_waiting(struct se_session *);
void target_wait_for_sess_cmds(struct se_session *, int);
--
1.7.2.5
--
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] isci: add CONFIG_PM_SLEEP to suspend/resume functions
On Tue, 26 Mar 2013 00:01:38 -0700 Jingoo Han wrote:
> Add CONFIG_PM_SLEEP to suspend/resume functions to fix the following
> build warning when CONFIG_PM_SLEEP is not selected. This is because
> sleep PM callbacks defined by SIMPLE_DEV_PM_OPS are only used when
> the CONFIG_PM_SLEEP is enabled.
>
> drivers/scsi/isci/init.c:725:12: warning: 'isci_suspend' defined but not used
> [-
> Wunused-function]
> drivers/scsi/isci/init.c:743:12: warning: 'isci_resume' defined but not used
> [-
> Wunused-function]
>
> Signed-off-by: Jingoo Han
Acked-by: Lukasz Dorau
> ---
> drivers/scsi/isci/init.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/scsi/isci/init.c b/drivers/scsi/isci/init.c
> index 2839baa..d25d0d8 100644
> --- a/drivers/scsi/isci/init.c
> +++ b/drivers/scsi/isci/init.c
> @@ -721,7 +721,7 @@ static void isci_pci_remove(struct pci_dev *pdev)
> }
> }
>
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
> static int isci_suspend(struct device *dev)
> {
> struct pci_dev *pdev = to_pci_dev(dev);
> @@ -770,18 +770,16 @@ static int isci_resume(struct device *dev)
>
> return 0;
> }
> +#endif
>
> static SIMPLE_DEV_PM_OPS(isci_pm_ops, isci_suspend, isci_resume);
> -#endif
>
> static struct pci_driver isci_pci_driver = {
> .name = DRV_NAME,
> .id_table = isci_id_table,
> .probe = isci_pci_probe,
> .remove = isci_pci_remove,
> -#ifdef CONFIG_PM
> .driver.pm = &isci_pm_ops,
> -#endif
> };
>
> static __init int isci_init(void)
> --
> 1.7.2.5
--
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: [RFC-v3 9/9] iser-target: Add iSCSI Extensions for RDMA (iSER) target driver
On 04/04/2013 10:24, Nicholas A. Bellinger wrote: + +void isert_cq_tx_callback(struct ib_cq *, void *); +void isert_cq_rx_callback(struct ib_cq *, void *); +void isert_free_rx_descriptors(struct isert_conn *); any reason not to have these as static functions (same for isert_cq_rx_work) -- 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: [RFC-v3 9/9] iser-target: Add iSCSI Extensions for RDMA (iSER) target driver
On 04/04/2013 10:24, Nicholas A. Bellinger wrote:
+#define ISER_RECV_DATA_SEG_LEN 8192
+#define ISER_RX_PAYLOAD_SIZE(ISER_HEADERS_LEN + ISER_RECV_DATA_SEG_LEN)
[...]
+#define ISER_RX_PAD_SIZE (16384 - (ISER_RX_PAYLOAD_SIZE + \
+ sizeof(u64) + sizeof(struct ib_sge)))
We're eating here too much ram for the pad, you need 8K + something, so
the pad can count down
from 12K and not 16K which means each such element will consume three
pages and not four.
+struct iser_rx_desc {
+ struct iser_hdr iser_header;
+ struct iscsi_hdr iscsi_header;
+ chardata[ISER_RECV_DATA_SEG_LEN];
+ u64 dma_addr;
+ struct ib_sge rx_sg;
+ charpad[ISER_RX_PAD_SIZE];
+} __packed;
+
+struct isert_rx_desc {
+ struct isert_conn *desc_conn;
+ struct work_struct desc_work;
+ struct iser_rx_desc desc;
+} __packed;
You have way enough room in the pad field of struct iser_rx_desc to
place there the two fields
added by struct isert_rx_desc (and you only use struct iser_rx_desc from
within isert_rx_desc) --> any reason
not to unify them?
Or.
--
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: [RFC-v3 9/9] iser-target: Add iSCSI Extensions for RDMA (iSER) target driver
On 04/04/2013 10:24, Nicholas A. Bellinger wrote:
+static int
+isert_put_response(struct iscsi_conn *conn, struct iscsi_cmd *cmd)
+{
+ struct isert_cmd *isert_cmd = container_of(cmd,
+ struct isert_cmd, iscsi_cmd);
+ struct isert_conn *isert_conn = (struct isert_conn *)conn->context;
+ struct ib_send_wr *send_wr = &isert_cmd->tx_desc.send_wr;
+ struct iscsi_scsi_rsp *hdr = (struct iscsi_scsi_rsp *)
+ &isert_cmd->tx_desc.iscsi_header;
+
+ isert_create_send_desc(isert_conn, isert_cmd, &isert_cmd->tx_desc);
+ iscsit_build_rsp_pdu(cmd, conn, true, hdr);
+ isert_init_tx_hdrs(isert_conn, &isert_cmd->tx_desc);
+ /*
+* Attach SENSE DATA payload to iSCSI Response PDU
+*/
+ if (cmd->se_cmd.sense_buffer &&
+ ((cmd->se_cmd.se_cmd_flags & SCF_TRANSPORT_TASK_SENSE) ||
+ (cmd->se_cmd.se_cmd_flags & SCF_EMULATED_TASK_SENSE))) {
+ struct ib_device *ib_dev = isert_conn->conn_cm_id->device;
+ struct ib_sge *tx_dsg = &isert_cmd->tx_desc.tx_sg[1];
+ u32 padding, sense_len;
+
+ put_unaligned_be16(cmd->se_cmd.scsi_sense_length,
+ cmd->sense_buffer);
+ cmd->se_cmd.scsi_sense_length += sizeof(__be16);
+
+ padding = -(cmd->se_cmd.scsi_sense_length) & 3;
+ hton24(hdr->dlength, (u32)cmd->se_cmd.scsi_sense_length);
+ sense_len = cmd->se_cmd.scsi_sense_length + padding;
+
+ isert_cmd->sense_buf_dma = ib_dma_map_single(ib_dev,
+ (void *)cmd->sense_buffer, sense_len,
+ DMA_TO_DEVICE);
+
+ isert_cmd->sense_buf_len = sense_len;
+ ib_dma_sync_single_for_cpu(ib_dev, isert_cmd->sense_buf_dma,
+ sense_len, DMA_TO_DEVICE);
+ ib_dma_sync_single_for_device(ib_dev, isert_cmd->sense_buf_dma,
+ sense_len, DMA_TO_DEVICE);
+
you just called dma_map_single, and not going to touch the buffer before
posting it to the wire,
there's no point to sync it for the cpu and for the device, remove these
calls.
+ tx_dsg->addr = isert_cmd->sense_buf_dma;
+ tx_dsg->length = sense_len;
+ tx_dsg->lkey = isert_conn->conn_mr->lkey;
+ isert_cmd->tx_desc.num_sge = 2;
+ }
+
+ isert_init_send_wr(isert_cmd, send_wr);
+
+ pr_debug("Posting SCSI Response IB_WR_SEND >>\n");
+
+ return isert_post_response(isert_conn, isert_cmd);
+}
--
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 0/4] scsi: 64-bit LUN support
On 03/31/2013 07:44 PM, Tomas Henzl wrote: > On 03/30/2013 05:53 PM, Hannes Reinecke wrote: >> On 03/29/2013 05:32 PM, Tomas Henzl wrote: [ .. ] >>> >>> in scsi_report_lun_scan is max_lun compared with the result of >>> scsilun_to_int, >>> but in that value is also stored the address method. This means, that we >>> compare >>> the max_lun to a LUN 'handle' which doesn't seem to make much sense. >>> This makes that test dependent on which address method is used and not >>> only to the LUN number which is I think expected. >>> The solution is to have a new function 'scsilun_to_num', (I can send a >>> patch) >>> or let the individual drivers set the max_lun to -1 and test for the >>> allowed LUNs >>> in the driver. >>> >> You sure this is necessary? > > This is not directly related to your 64bit patch, I just 'used' this thread > to discuss another issue - sorry. > Yeah, and thereby decreasing the chance of getting my patchset in :-( >> >> I would like to avoid having to parse the LUN number for validity as we >> cannot guarantee this check has any meaning for the target. >> The only authoritative check can be made by the target. > > What we can do is to decode the LUN and compare it to max_lun provided by the > driver, > I think that sg_luns is able to do that, so what is needed is just to follow > the SAM. > > I have seen reports of problem on three different drivers connected to > various > external storage, all of them having the same basic reason - the driver sets > a max_lun > and then LUN comes encoded with a newer addressing method and something like > this is shown > 'kernel: scsi: host 2 channel 0 id 2 lun16643 has a LUN larger than allowed > by the host adapter' > > Decoding the real LUN value would fix this problem, by decoding is only meant > the use in > scsi_report_lun_scan. The LUN would be stored exactly the same way as it is > now. > I know we can patch the certain drivers too, but when max_lun were what the > name says > - max LU number, it would fix my problem very easy. > Errm. No. Decoding LUNs is _evil_. It has only a relevance on the target, and even then it might choose to ignore it. So we cannot try to out-guess the target here. The error you're reporting is that lpfc is setting max_luns to '255', which of course is less than 16643. Increasing max_luns on lpfc to '0x' will fix your problem; nothing to do with 64-bit LUNs ... >> >> In the 64-bit context the max_luns should rather be interpreted as a >> 'max bits' setting, ie the number of _bits_ per LUN number the HBA is >> able to transport. >> But renaming 'max_luns' to 'max_bits' is a bit pointless, as it would >> break backwards compability for no real gain. >> >> So with my patchset we have a two-step LUN validation: >> - max_luns controls the max LUN number >>(read: max number of bits per LUN) which can be transported >>to the target > > This means in fact only 32 or 64 bit - so a single bit flag is enough? > No, it is not. We have SPI narrow with max_luns = 8, SPI wide with max_luns = 16, some (older) FC HBAs supporting only 8 or 16 bits LUNs, some RAID arrays supporting 32-bit LUNs etc. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
scanning for LUNs
Here is the code snippet for scanning LUNS (drivers/scsi/scsi_scan.c in
function
__scsi_scan_target()):
/*
* Scan LUN 0, if there is some response, scan further. Ideally, we
* would not configure LUN 0 until all LUNs are scanned.
*/
res = scsi_probe_and_add_lun(starget, 0, &bflags, NULL, rescan, NULL);
if (res == SCSI_SCAN_LUN_PRESENT || res == SCSI_SCAN_TARGET_PRESENT) {
if (scsi_report_lun_scan(starget, bflags, rescan) != 0)
So, if we don't get a response while scanning LUN0, we will not use
scsi_report_lun_scan().
On Hyper-V, the scsi emulation on the host does not treat LUN0 as anything
special and we
could have situations where the only device under a scsi controller is at a
location other than 0
or 1. In this case the standard LUN scanning code in Linux fails to detect this
device. Is this
behaviour expected? Why is LUN0 treated differently here. Looking at the scsi
spec, I am not sure
if this is what is specified. Any help/guidance will be greatly appreciated.
Regards,
K. Y
--
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
[dm-devel] [PATCH] [RESEND] scsi_dh_alua: Add module parameter to allow failover to non preferred path without STPG
Resending with requested rewording of the parameter description.
Currently ALUA device handler sends STPG command during failover and failback.
Failover can be optimized by implicit failover (by not to sending STPG
command), when 1 is passed as hwhandler parameter in multipath.conf. ex "2 alua
1". We may need to pass the parameter through module param for alua device
handler to optimize failover if incase retain_attached_hwhandler set in
multipath.conf and hwhandler is set with non-tpgs device handler ex: '1 rdac'.
Signed-off-by: Vijay Chauhan
Signed-off-by: Sean Stewart
---
--- a/drivers/scsi/device_handler/scsi_dh_alua.c.orig 2013-03-27
12:18:35.0 +0530
+++ b/drivers/scsi/device_handler/scsi_dh_alua.c2013-03-27
13:23:16.0 +0530
@@ -710,6 +710,10 @@ static int alua_set_params(struct scsi_d
return result;
}
+static uint optimize_stpg;
+module_param(optimize_stpg, uint, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(optimize_stpg, "Allow use of a non-optimized path,
+rather than sending a STPG, when implicit TPGS is supported (0=No,1=Yes).
Default is 0.");
+
/*
* alua_activate - activate a path
* @sdev: device on the path to be activated @@ -731,6 +735,9 @@ static int
alua_activate(struct scsi_dev
if (err != SCSI_DH_OK)
goto out;
+ if (optimize_stpg)
+ h->flags |= ALUA_OPTIMIZE_STPG;
+
if (h->tpgs & TPGS_MODE_EXPLICIT) {
switch (h->state) {
case TPGS_STATE_NONOPTIMIZED:
--
--
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: scanning for LUNs
On Thu, 2013-04-04 at 08:12 -0700, K. Y. Srinivasan wrote:
> Here is the code snippet for scanning LUNS (drivers/scsi/scsi_scan.c in
> function
> __scsi_scan_target()):
>
> /*
> * Scan LUN 0, if there is some response, scan further. Ideally, we
> * would not configure LUN 0 until all LUNs are scanned.
> */
> res = scsi_probe_and_add_lun(starget, 0, &bflags, NULL, rescan, NULL);
> if (res == SCSI_SCAN_LUN_PRESENT || res == SCSI_SCAN_TARGET_PRESENT) {
> if (scsi_report_lun_scan(starget, bflags, rescan) != 0)
>
>
> So, if we don't get a response while scanning LUN0, we will not use
> scsi_report_lun_scan().
> On Hyper-V, the scsi emulation on the host does not treat LUN0 as
> anything special and we
> could have situations where the only device under a scsi controller is
> at a location other than 0
> or 1. In this case the standard LUN scanning code in Linux fails to
> detect this device. Is this
> behaviour expected? Why is LUN0 treated differently here. Looking at
> the scsi spec, I am not sure
> if this is what is specified. Any help/guidance will be greatly
> appreciated.
Why don't you describe the problem. We can't scan randomly a bunch of
LUNs hoping for a response (the space is 10^19). SAM thinks you use
LUNW for this, but that's not well supported. We can't annoy USB
devices by probing with REPORT LUNS, so conventionally most arrays
return something for LUN0 even if they don't actually have one (That's
what the peripheral qualifier codes are supposed to be about). We
translate PQ1 and PQ2 to SCSI_SCAN_TARGET_PRESENT, which means no LUN,
but there is a target to scan here.
If you're sending back an error to an INQUIRY to LUN0, then you're out
of spec. The SCSI standards say:
SPC3 6.4.1: In response to an INQUIRY command received by an
incorrect logical unit, the SCSI target device shall return the
INQUIRY data with the peripheral qualifier set to the value
defined in 6.4.2. The INQUIRY command shall return CHECK
CONDITION status only when the device server is unable to return
the requested INQUIRY data
James
James
--
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: scanning for LUNs
> -Original Message-
> From: James Bottomley [mailto:jbottom...@parallels.com]
> Sent: Thursday, April 04, 2013 11:15 AM
> To: KY Srinivasan
> Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; oher...@suse.com; h...@infradead.org; linux-
> s...@vger.kernel.org
> Subject: Re: scanning for LUNs
>
> On Thu, 2013-04-04 at 08:12 -0700, K. Y. Srinivasan wrote:
> > Here is the code snippet for scanning LUNS (drivers/scsi/scsi_scan.c in
> > function
> > __scsi_scan_target()):
> >
> > /*
> > * Scan LUN 0, if there is some response, scan further. Ideally, we
> > * would not configure LUN 0 until all LUNs are scanned.
> > */
> > res = scsi_probe_and_add_lun(starget, 0, &bflags, NULL, rescan,
> > NULL);
> > if (res == SCSI_SCAN_LUN_PRESENT || res ==
> SCSI_SCAN_TARGET_PRESENT) {
> > if (scsi_report_lun_scan(starget, bflags, rescan) != 0)
> >
> >
> > So, if we don't get a response while scanning LUN0, we will not use
> > scsi_report_lun_scan().
> > On Hyper-V, the scsi emulation on the host does not treat LUN0 as
> > anything special and we
> > could have situations where the only device under a scsi controller is
> > at a location other than 0
> > or 1. In this case the standard LUN scanning code in Linux fails to
> > detect this device. Is this
> > behaviour expected? Why is LUN0 treated differently here. Looking at
> > the scsi spec, I am not sure
> > if this is what is specified. Any help/guidance will be greatly
> > appreciated.
>
> Why don't you describe the problem. We can't scan randomly a bunch of
> LUNs hoping for a response (the space is 10^19). SAM thinks you use
> LUNW for this, but that's not well supported. We can't annoy USB
> devices by probing with REPORT LUNS, so conventionally most arrays
> return something for LUN0 even if they don't actually have one (That's
> what the peripheral qualifier codes are supposed to be about). We
> translate PQ1 and PQ2 to SCSI_SCAN_TARGET_PRESENT, which means no LUN,
> but there is a target to scan here.
>
> If you're sending back an error to an INQUIRY to LUN0, then you're out
> of spec. The SCSI standards say:
>
> SPC3 6.4.1: In response to an INQUIRY command received by an
> incorrect logical unit, the SCSI target device shall return the
> INQUIRY data with the peripheral qualifier set to the value
> defined in 6.4.2. The INQUIRY command shall return CHECK
> CONDITION status only when the device server is unable to return
> the requested INQUIRY data
Thanks James. I will further investigate the issue on our platform.
Regards,
K. Y
>
> James
>
>
> James
>
>
--
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 2/3] PCI: Handle device quirks when accessing sysfs resource entries
On Thu, Mar 21, 2013 at 6:51 PM, Robert Hancock wrote: > On 03/20/2013 10:35 PM, Myron Stowe wrote: >> >> Sysfs includes entries to memory regions that back a PCI device's BARs. >> The pci-sysfs entries backing I/O Port BARs can be accessed by userspace, >> providing direct access to the device's registers. File permissions >> prevent random users from accessing the device's registers through these >> files, but don't stop a privileged app that chooses to ignore the purpose >> of these files from doing so. >> >> There are devices with abnormally strict restrictions with respect to >> accessing their registers; aspects that are typically handled by the >> device's driver. When these access restrictions are not followed - as >> when a userspace app such as "udevadm info --attribute-walk >> --path=/sys/..." parses though reading all the device's sysfs entries - it >> can cause such devices to fail. >> >> This patch introduces a quirking mechanism that can be used to detect >> accesses that do no meet the device's restrictions, letting a device >> specific method intervene and decide how to progress. >> >> Reported-by: Xiangliang Yu >> Signed-off-by: Myron Stowe > > > I honestly don't think there's much point in even attempting this strategy. > This list of devices in the quirk can't possibly be complete. It would > likely be easier to enumerate a white-list of devices that can deal with > their IO ports being read willy-nilly than a blacklist of those that don't, > as there's likely countless devices that fall into this category. Even if > they don't choke as badly as these ones do, it's quite likely that bad > behavior will result. I agree, I'm not inclined to add a bunch of code that only fixes one device when there are likely many others with similar problems. > I think there's a few things that need to be done: > > -Fix the bug in udevadm that caused it to trawl through these files > willy-nilly, We can argue about whether this is actually a bug in udevadm, but either way, my opinion is that the data that udevadm prints out from these files is uninteresting in the same way the data from "uevent," "dev," "modalias," "resource," etc. is uninteresting. So to me, a udevadm change seems justified for that reason. > -Fix the kernel so that access through these files complies with the > kernel's mechanisms for claiming IO/memory regions to prevent access > conflicts (i.e. opening these files should claim the resource region they > refer to, and should fail with EBUSY or something if another process or a > kernel driver is using it). > > -Reconsider whether supporting read/write on the resource files for IO port > regions like these makes any sense. Obviously mmap isn't very practical for > IO port access on x86 but you could even do something like an ioctl for this > purpose. Not very many pieces of software would need to access these files > so it's likely OK if the API is a bit ugly. That would prevent something > like grepping through sysfs from generating port accesses to random devices. This is the approach I'd like to push on for a kernel fix. I'm not a VM person, but if it were possible to support .mmap() in such a way that a handler would be called for every access to the region, we could easily support I/O port access that way. Along that line, I'm concerned that we may have a hole in the MEM BAR .mmap() path. What happens if we have BARs from two different devices in the same page, and we mmap() one of them? Does the user also get access to the second device's BAR on the same page? If so, that could also be fixed with an .mmap() trap approach. Performance would suck for these small BARs, of course. Bjorn -- 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
PING^3 Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542)
Il 22/03/2013 23:30, Paolo Bonzini ha scritto: > Il 20/02/2013 17:12, Paolo Bonzini ha scritto: >> Il 06/02/2013 16:15, Paolo Bonzini ha scritto: >>> This series regards the whitelist that is used for the SG_IO ioctl. This >>> whitelist has three problems: >>> >>> * the bitmap of allowed commands is designed for MMC devices (roughly, >>> "play/burn CDs without requiring root") but some opcodes overlap across >>> SCSI >>> device classes and have different meanings for different classes. >>> >>> * also because the bitmap of allowed commands is designed for MMC devices >>> only, some commands are missing even though they are generally useful and >>> not insecure. At least not more insecure than anything else you can >>> do if you have access to /dev/sdX or /dev/stX nodes. >>> >>> * the whitelist can be disabled per-process but not per-disk. In addition, >>> the required capability (CAP_SYS_RAWIO) gives access to a range of other >>> resources, enough to make it insecure. >>> >>> The series corrects these problems. Patches 1-4 solve the first problem, >>> which also has an assigned CVE, by using different bitmaps for the various >>> device classes. Patches 5-11 solve the second by adding more commands >>> to the bitmaps. Patches 12 and 13 solve the third, and were already >>> posted but ignored by the maintainers despite multiple pings. >>> >>> Note: checkpatch hates the formatting of the command table. I know about >>> this, >>> and ensured that there are no errors in the rest of the code. The current >>> formatting is IMHO quite handy, and roughly based on the files available >>> from the SCSI standard body. >>> >>> Ok for the next merge window? >>> >>> Paolo >>> >>> v1->v2: remove 2 MMC commands and 6 SBC commands (see patches 6 and 9 >>> for details). Added patch 14 and added a few more scanner >>> commands based on SANE (scanners are not whitelisted by default, >>> also were not in v1, but this makes it possible to opt into the >>> whitelist out of paranoia). Removed C++ comments. Removed the >>> large #if 0'd list of commands that the kernel does not pass >>> though. Marked blk_set_cmd_filter_defaults as __init. >> >> Ping... >> >> Jens/James, is anyone going to pick this up for 3.9? > > Another month has passed, Ping^2... Ping^3, any hope for 3.10? Paolo > > Paolo > >> Paolo >> >>> >>> Paolo Bonzini (14): >>> sg_io: pass request_queue to blk_verify_command >>> sg_io: reorganize list of allowed commands >>> sg_io: use different default filters for each device class >>> sg_io: resolve conflicts between commands assigned to multiple >>> classes (CVE-2012-4542) >>> sg_io: whitelist a few more commands for rare & obsolete device types >>> sg_io: whitelist another command for multimedia devices >>> sg_io: whitelist a few more commands for media changers >>> sg_io: whitelist a few more commands for tapes >>> sg_io: whitelist a few more commands for disks >>> sg_io: whitelist a few obsolete commands >>> sg_io: mark blk_set_cmd_filter_defaults as __init >>> sg_io: remove remnants of sysfs SG_IO filters >>> sg_io: introduce unpriv_sgio queue flag >>> sg_io: use unpriv_sgio to disable whitelisting for scanners >>> >>> Documentation/block/queue-sysfs.txt |8 + >>> block/blk-sysfs.c | 33 +++ >>> block/bsg.c |2 +- >>> block/scsi_ioctl.c | 369 >>> ++- >>> drivers/scsi/scsi_scan.c| 14 ++- >>> drivers/scsi/sg.c |6 +- >>> include/linux/blkdev.h |8 +- >>> include/linux/genhd.h |9 - >>> include/scsi/scsi.h |3 + >>> 9 files changed, 344 insertions(+), 108 deletions(-) >>> >> > -- 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 3/3] PCI, scsi, ahci: Unify usages of 0x1b4b vendor ID to use PCI_VENDOR_ID_MARVELL_EXT
On Wed, Mar 20, 2013 at 10:35 PM, Myron Stowe wrote:
> With the 0x1b4b vendor ID #define in place, convert hard-coded ID values.
> Also, unify the previous SCSI specific use of this vendor ID to the new
> macro.
>
> Signed-off-by: Myron Stowe
> ---
>
> drivers/ata/ahci.c | 10 +-
> drivers/scsi/mvsas/mv_init.c |6 +++---
> drivers/scsi/mvumi.c |4 ++--
> drivers/scsi/mvumi.h |1 -
> 4 files changed, 10 insertions(+), 11 deletions(-)
Jeff & James, if you don't object to these, I can push them through my
PCI tree along with the corresponding pci_ids.h addition.
Or I can just make the pci_ids.h change and you can take these if you'd prefer.
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index a99112c..616952f 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -413,17 +413,17 @@ static const struct pci_device_id ahci_pci_tbl[] = {
> /* Marvell */
> { PCI_VDEVICE(MARVELL, 0x6145), board_ahci_mv },/* 6145 */
> { PCI_VDEVICE(MARVELL, 0x6121), board_ahci_mv },/* 6121 */
> - { PCI_DEVICE(0x1b4b, 0x9123),
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9123),
> .class = PCI_CLASS_STORAGE_SATA_AHCI,
> .class_mask = 0xff,
> .driver_data = board_ahci_yes_fbs }, /* 88se9128 */
> - { PCI_DEVICE(0x1b4b, 0x9125),
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9125),
> .driver_data = board_ahci_yes_fbs }, /* 88se9125 */
> - { PCI_DEVICE(0x1b4b, 0x917a),
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x917a),
> .driver_data = board_ahci_yes_fbs }, /* 88se9172 */
> - { PCI_DEVICE(0x1b4b, 0x9192),
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9192),
> .driver_data = board_ahci_yes_fbs }, /* 88se9172
> on some Gigabyte */
> - { PCI_DEVICE(0x1b4b, 0x91a3),
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x91a3),
> .driver_data = board_ahci_yes_fbs },
>
> /* Promise */
> diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c
> index ce90d05..7455092 100644
> --- a/drivers/scsi/mvsas/mv_init.c
> +++ b/drivers/scsi/mvsas/mv_init.c
> @@ -703,7 +703,7 @@ static struct pci_device_id mvs_pci_table[] = {
> { PCI_VDEVICE(TTI, 0x2744), chip_9480 },
> { PCI_VDEVICE(TTI, 0x2760), chip_9480 },
> {
> - .vendor = 0x1b4b,
> + .vendor = PCI_VENDOR_ID_MARVELL_EXT,
> .device = 0x9480,
> .subvendor = PCI_ANY_ID,
> .subdevice = 0x9480,
> @@ -712,7 +712,7 @@ static struct pci_device_id mvs_pci_table[] = {
> .driver_data= chip_9480,
> },
> {
> - .vendor = 0x1b4b,
> + .vendor = PCI_VENDOR_ID_MARVELL_EXT,
> .device = 0x9445,
> .subvendor = PCI_ANY_ID,
> .subdevice = 0x9480,
> @@ -721,7 +721,7 @@ static struct pci_device_id mvs_pci_table[] = {
> .driver_data= chip_9445,
> },
> {
> - .vendor = 0x1b4b,
> + .vendor = PCI_VENDOR_ID_MARVELL_EXT,
> .device = 0x9485,
> .subvendor = PCI_ANY_ID,
> .subdevice = 0x9480,
> diff --git a/drivers/scsi/mvumi.c b/drivers/scsi/mvumi.c
> index 4594cca..c3601b5 100644
> --- a/drivers/scsi/mvumi.c
> +++ b/drivers/scsi/mvumi.c
> @@ -49,8 +49,8 @@ MODULE_AUTHOR("j...@marvell.com");
> MODULE_DESCRIPTION("Marvell UMI Driver");
>
> static DEFINE_PCI_DEVICE_TABLE(mvumi_pci_table) = {
> - { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_2, PCI_DEVICE_ID_MARVELL_MV9143) },
> - { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_2, PCI_DEVICE_ID_MARVELL_MV9580) },
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, PCI_DEVICE_ID_MARVELL_MV9143)
> },
> + { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, PCI_DEVICE_ID_MARVELL_MV9580)
> },
> { 0 }
> };
>
> diff --git a/drivers/scsi/mvumi.h b/drivers/scsi/mvumi.h
> index e360135..41f1687 100644
> --- a/drivers/scsi/mvumi.h
> +++ b/drivers/scsi/mvumi.h
> @@ -32,7 +32,6 @@
> #define VER_BUILD 1500
>
> #define MV_DRIVER_NAME "mvumi"
> -#define PCI_VENDOR_ID_MARVELL_20x1b4b
> #define PCI_DEVICE_ID_MARVELL_MV9143 0x9143
> #define PCI_DEVICE_ID_MARVELL_MV9580 0x9580
>
>
--
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: [RFC-v3 9/9] iser-target: Add iSCSI Extensions for RDMA (iSER) target driver
On Thu, 2013-04-04 at 12:20 +0300, Or Gerlitz wrote: > On 04/04/2013 10:24, Nicholas A. Bellinger wrote: > > + > > +void isert_cq_tx_callback(struct ib_cq *, void *); > > +void isert_cq_rx_callback(struct ib_cq *, void *); > > +void isert_free_rx_descriptors(struct isert_conn *); > any reason not to have these as static functions (same for isert_cq_rx_work) Nope. Looking at re-orig now to avoid the use of function prototypes here, and marking everything as static.. --nab -- 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: [RFC-v3 9/9] iser-target: Add iSCSI Extensions for RDMA (iSER) target driver
On Thu, 2013-04-04 at 12:45 +0300, Or Gerlitz wrote:
> On 04/04/2013 10:24, Nicholas A. Bellinger wrote:
>
> > +#define ISER_RECV_DATA_SEG_LEN 8192
> > +#define ISER_RX_PAYLOAD_SIZE(ISER_HEADERS_LEN + ISER_RECV_DATA_SEG_LEN)
> > [...]
> > +#define ISER_RX_PAD_SIZE (16384 - (ISER_RX_PAYLOAD_SIZE + \
> > + sizeof(u64) + sizeof(struct ib_sge)))
>
> We're eating here too much ram for the pad, you need 8K + something, so
> the pad can count down
> from 12K and not 16K which means each such element will consume three
> pages and not four.
>
Hmm, IIRC this larger pad was originally required after bumping the
ISER_RECV_DATA_SEG_LEN value for handling incoming ImmediateData and
Unsolicited Data-OUT.. Will try using 12k here and see what happens..
Also, ISER_RECV_DATA_SEG_LEN will need to be enforced as the largest
MaxRecvDataSegmentLength negotiated during iser login to prevent the
initiator from exceeding the hardcoded value..
> > +struct iser_rx_desc {
> > + struct iser_hdr iser_header;
> > + struct iscsi_hdr iscsi_header;
> > + chardata[ISER_RECV_DATA_SEG_LEN];
> > + u64 dma_addr;
> > + struct ib_sge rx_sg;
> > + charpad[ISER_RX_PAD_SIZE];
> > +} __packed;
> > +
> > +struct isert_rx_desc {
> > + struct isert_conn *desc_conn;
> > + struct work_struct desc_work;
> > + struct iser_rx_desc desc;
> > +} __packed;
>
> You have way enough room in the pad field of struct iser_rx_desc to
> place there the two fields
> added by struct isert_rx_desc (and you only use struct iser_rx_desc from
> within isert_rx_desc) --> any reason
> not to unify them?
>
This is left-over cruft from the per isert_rx_desc dispatch into process
context.. Dropping this now.
--nab
--
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: [RFC-v3 9/9] iser-target: Add iSCSI Extensions for RDMA (iSER) target driver
On Thu, 2013-04-04 at 12:51 +0300, Or Gerlitz wrote:
> On 04/04/2013 10:24, Nicholas A. Bellinger wrote:
> > +static int
> > +isert_put_response(struct iscsi_conn *conn, struct iscsi_cmd *cmd)
> > +{
> > + struct isert_cmd *isert_cmd = container_of(cmd,
> > + struct isert_cmd, iscsi_cmd);
> > + struct isert_conn *isert_conn = (struct isert_conn *)conn->context;
> > + struct ib_send_wr *send_wr = &isert_cmd->tx_desc.send_wr;
> > + struct iscsi_scsi_rsp *hdr = (struct iscsi_scsi_rsp *)
> > + &isert_cmd->tx_desc.iscsi_header;
> > +
> > + isert_create_send_desc(isert_conn, isert_cmd, &isert_cmd->tx_desc);
> > + iscsit_build_rsp_pdu(cmd, conn, true, hdr);
> > + isert_init_tx_hdrs(isert_conn, &isert_cmd->tx_desc);
> > + /*
> > +* Attach SENSE DATA payload to iSCSI Response PDU
> > +*/
> > + if (cmd->se_cmd.sense_buffer &&
> > + ((cmd->se_cmd.se_cmd_flags & SCF_TRANSPORT_TASK_SENSE) ||
> > + (cmd->se_cmd.se_cmd_flags & SCF_EMULATED_TASK_SENSE))) {
> > + struct ib_device *ib_dev = isert_conn->conn_cm_id->device;
> > + struct ib_sge *tx_dsg = &isert_cmd->tx_desc.tx_sg[1];
> > + u32 padding, sense_len;
> > +
> > + put_unaligned_be16(cmd->se_cmd.scsi_sense_length,
> > + cmd->sense_buffer);
> > + cmd->se_cmd.scsi_sense_length += sizeof(__be16);
> > +
> > + padding = -(cmd->se_cmd.scsi_sense_length) & 3;
> > + hton24(hdr->dlength, (u32)cmd->se_cmd.scsi_sense_length);
> > + sense_len = cmd->se_cmd.scsi_sense_length + padding;
> > +
> > + isert_cmd->sense_buf_dma = ib_dma_map_single(ib_dev,
> > + (void *)cmd->sense_buffer, sense_len,
> > + DMA_TO_DEVICE);
> > +
> > + isert_cmd->sense_buf_len = sense_len;
> > + ib_dma_sync_single_for_cpu(ib_dev, isert_cmd->sense_buf_dma,
> > + sense_len, DMA_TO_DEVICE);
> > + ib_dma_sync_single_for_device(ib_dev, isert_cmd->sense_buf_dma,
> > + sense_len, DMA_TO_DEVICE);
> > +
>
> you just called dma_map_single, and not going to touch the buffer before
> posting it to the wire,
> there's no point to sync it for the cpu and for the device, remove these
> calls.
>
Dropped.
Thanks Or!
--
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: [dm-devel] [PATCH] scsi-dh-emc: fix activate vs set_params race
On 04/02/2013 07:09 PM, Mikulas Patocka wrote: > Hi > > This fixes a possible race in scsi_dh_emc. It is untested because I don't > have the hardware. It could happen when we reload a multipath device and > path failure happens at the same time. I think this patch is ok. I do not have the hw to test it anymore. If you wanted to test just to make sure it is safe you should bug Rob Evers. He can help you find a machine in the westford lab that has it -- 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: [dm-devel] [PATCH] scsi-dh-emc: fix activate vs set_params race
I can test it. I have a clarion Cx3 Will get to it next week, traveling tomorrow Laurence Sent from my iPhone On Apr 4, 2013, at 7:11 PM, Mike Christie wrote: > On 04/02/2013 07:09 PM, Mikulas Patocka wrote: >> Hi >> >> This fixes a possible race in scsi_dh_emc. It is untested because I don't >> have the hardware. It could happen when we reload a multipath device and >> path failure happens at the same time. > > > I think this patch is ok. I do not have the hw to test it anymore. > > If you wanted to test just to make sure it is safe you should bug Rob > Evers. He can help you find a machine in the westford lab that has it > -- > 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 -- 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
[OT] LDD3 Query
Hi, I am new to Linux Device Driver and reading LDD3. It mentions that the disadvantage of dynamic major number allocation is that you can’t create the device nodes in advance, because the major number assigned to your module will vary. To solve this problem, it says that create a script to invoke insmod and after calling insmod, reads /proc/devices in order to create the special file(s). My question is, is there no way to do it inside the module? How other modules does? --- Vijay -- 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
