Re: [PATCH 2/3] scsi: iscsi: make iscsi_flashnode_bus const

['Lee Duncan' via open-iscsi]

On Sat, Feb 3, 2024 at 10:38 AM Ricardo B. Marliere
 wrote:
>
> Now that the driver core can properly handle constant struct bus_type,
> move the iscsi_flashnode_bus variable to be a constant structure as well,
> placing it into read-only memory which can not be modified at runtime.
>
> Cc: Greg Kroah-Hartman 
> Suggested-by: Greg Kroah-Hartman 
> Signed-off-by: Ricardo B. Marliere 
> ---
>  drivers/scsi/scsi_transport_iscsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> index 3075b2ddf7a6..af3ac6346796 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -1201,7 +1201,7 @@ static const struct device_type 
> iscsi_flashnode_conn_dev_type = {
> .release = iscsi_flashnode_conn_release,
>  };
>
> -static struct bus_type iscsi_flashnode_bus;
> +static const struct bus_type iscsi_flashnode_bus;
>
>  int iscsi_flashnode_bus_match(struct device *dev,
>  struct device_driver *drv)
> @@ -1212,7 +1212,7 @@ int iscsi_flashnode_bus_match(struct device *dev,
>  }
>  EXPORT_SYMBOL_GPL(iscsi_flashnode_bus_match);
>
> -static struct bus_type iscsi_flashnode_bus = {
> +static const struct bus_type iscsi_flashnode_bus = {
> .name = "iscsi_flashnode",
> .match = _flashnode_bus_match,
>  };
>
> --
> 2.43.0
>

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CAPj3X_UbiLY4MQaUjHkijpSi1LvjG-1BSfO5td7rk__2weshZQ%40mail.gmail.com.

Re: 回复: [PATCH v1] scsi: iscsi: use kfree_sensitive() in iscsi_session_free()

['Lee Duncan' via open-iscsi]

On 7/18/23 19:28, 杜敏杰 wrote:

Hi Mike!

Thank you for your reply!
Do I need to submit a new patch to kfree_sensitive for 'password_in' and 
'usernames'?



Just submit a V2 version of your original patch, making the changes that 
Mike suggested. You can continue to include my Reviewed-by tag.




regards,
Minjie

-邮件原件-
发件人: Mike Christie 
发送时间: 2023年7月18日 2:26
收件人: 杜敏杰 ; Lee Duncan ; Chris Leech ; James E.J. 
Bottomley ; Martin K. Petersen ; open list:ISCSI 
; open list:ISCSI ; open list 

抄送: opensource.kernel 
主题: Re: [PATCH v1] scsi: iscsi: use kfree_sensitive() in iscsi_session_free()

On 7/17/23 4:26 AM, Minjie Du wrote:

session might contain private part of the password, so better use
kfree_sensitive() to free it.
In iscsi_session_free() use kfree_sensitive() to free session->password.

Signed-off-by: Minjie Du 
---
  drivers/scsi/libiscsi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c index
0fda8905e..2f273229c 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -3132,7 +3132,7 @@ void iscsi_session_free(struct iscsi_cls_session 
*cls_session)
struct module *owner = cls_session->transport->owner;
  
  	iscsi_pool_free(>cmdpool);

-   kfree(session->password);
+   kfree_sensitive(session->password);
kfree(session->password_in);


You then also want kfree_sensitive for password_in.

I would also use it for the usernames then too.


kfree(session->username);
kfree(session->username_in);




--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/7483deb3-2b69-37fa-28ea-fb54aac58ff8%40suse.com.

Re: [PATCH v1] scsi: iscsi: use kfree_sensitive() in iscsi_session_free()

['Lee Duncan' via open-iscsi]

On 7/17/23 02:26, Minjie Du wrote:

session might contain private part of the password, so better use
kfree_sensitive() to free it.
In iscsi_session_free() use kfree_sensitive() to free session->password.

Signed-off-by: Minjie Du 
---
  drivers/scsi/libiscsi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 0fda8905e..2f273229c 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -3132,7 +3132,7 @@ void iscsi_session_free(struct iscsi_cls_session 
*cls_session)
struct module *owner = cls_session->transport->owner;
  
  	iscsi_pool_free(>cmdpool);

-   kfree(session->password);
+   kfree_sensitive(session->password);
kfree(session->password_in);
kfree(session->username);
kfree(session->username_in);


Reviewed-by: Lee Duncan 

--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/cf71648c-eed0-cefb-ddff-1b2f7809dc3b%40suse.com.

Re: [RFC PATCH 2/9] iscsi: associate endpoints with a host

[Lee Duncan]

On Mar 14, 2023, at 9:23 AM, Hannes Reinecke  wrote:
> 
> On 2/8/23 18:40, Lee Duncan wrote:
>> From: Lee Duncan 
>> Right now the iscsi_endpoint is only linked to a connection once that
>> connection has been established.  For net namespace filtering of the
>> sysfs objects, associate an endpoint with the host that it was
>> allocated for when it is created.
>> Signed-off-by: Chris Leech 
>> Signed-off-by: Lee Duncan 
>> ---
>>  drivers/infiniband/ulp/iser/iscsi_iser.c | 2 +-
>>  drivers/scsi/be2iscsi/be_iscsi.c | 2 +-
>>  drivers/scsi/bnx2i/bnx2i_iscsi.c | 2 +-
>>  drivers/scsi/cxgbi/libcxgbi.c| 2 +-
>>  drivers/scsi/qedi/qedi_iscsi.c   | 2 +-
>>  drivers/scsi/qla4xxx/ql4_os.c| 2 +-
>>  drivers/scsi/scsi_transport_iscsi.c  | 3 ++-
>>  include/scsi/scsi_transport_iscsi.h  | 6 +-
>>  8 files changed, 13 insertions(+), 8 deletions(-)
>> diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c 
>> b/drivers/infiniband/ulp/iser/iscsi_iser.c
>> index 620ae5b2d80d..d38c909b462f 100644
>> --- a/drivers/infiniband/ulp/iser/iscsi_iser.c
>> +++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
>> @@ -802,7 +802,7 @@ static struct iscsi_endpoint 
>> *iscsi_iser_ep_connect(struct Scsi_Host *shost,
>>  struct iser_conn *iser_conn;
>>  struct iscsi_endpoint *ep;
>>  -   ep = iscsi_create_endpoint(0);
>> +ep = iscsi_create_endpoint(shost, 0);
>>  if (!ep)
>>  return ERR_PTR(-ENOMEM);
>>  diff --git a/drivers/scsi/be2iscsi/be_iscsi.c 
>> b/drivers/scsi/be2iscsi/be_iscsi.c
>> index 8aeaddc93b16..c893d193f5ef 100644
>> --- a/drivers/scsi/be2iscsi/be_iscsi.c
>> +++ b/drivers/scsi/be2iscsi/be_iscsi.c
>> @@ -1168,7 +1168,7 @@ beiscsi_ep_connect(struct Scsi_Host *shost, struct 
>> sockaddr *dst_addr,
>>  return ERR_PTR(ret);
>>  }
>>  -   ep = iscsi_create_endpoint(sizeof(struct beiscsi_endpoint));
>> +ep = iscsi_create_endpoint(shost, sizeof(struct beiscsi_endpoint));
>>  if (!ep) {
>>  ret = -ENOMEM;
>>  return ERR_PTR(ret);
>> diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c 
>> b/drivers/scsi/bnx2i/bnx2i_iscsi.c
>> index a3c800e04a2e..ac63e93e07c6 100644
>> --- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
>> +++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
>> @@ -384,7 +384,7 @@ static struct iscsi_endpoint *bnx2i_alloc_ep(struct 
>> bnx2i_hba *hba)
>>  struct bnx2i_endpoint *bnx2i_ep;
>>  u32 ec_div;
>>  -   ep = iscsi_create_endpoint(sizeof(*bnx2i_ep));
>> +ep = iscsi_create_endpoint(hba->shost, sizeof(*bnx2i_ep));
>>  if (!ep) {
>>  printk(KERN_ERR "bnx2i: Could not allocate ep\n");
>>  return NULL;
>> diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
>> index af281e271f88..94edf8e1fb0c 100644
>> --- a/drivers/scsi/cxgbi/libcxgbi.c
>> +++ b/drivers/scsi/cxgbi/libcxgbi.c
>> @@ -2926,7 +2926,7 @@ struct iscsi_endpoint *cxgbi_ep_connect(struct 
>> Scsi_Host *shost,
>>  goto release_conn;
>>  }
>>  -   ep = iscsi_create_endpoint(sizeof(*cep));
>> +ep = iscsi_create_endpoint(shost, sizeof(*cep));
>>  if (!ep) {
>>  err = -ENOMEM;
>>  pr_info("iscsi alloc ep, OOM.\n");
>> diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
>> index 31ec429104e2..4baf1dbb8e92 100644
>> --- a/drivers/scsi/qedi/qedi_iscsi.c
>> +++ b/drivers/scsi/qedi/qedi_iscsi.c
>> @@ -931,7 +931,7 @@ qedi_ep_connect(struct Scsi_Host *shost, struct sockaddr 
>> *dst_addr,
>>  return ERR_PTR(-ENXIO);
>>  }
>>  -   ep = iscsi_create_endpoint(sizeof(struct qedi_endpoint));
>> +ep = iscsi_create_endpoint(shost, sizeof(struct qedi_endpoint));
>>  if (!ep) {
>>  QEDI_ERR(>dbg_ctx, "endpoint create fail\n");
>>  ret = -ENOMEM;
>> diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
>> index 005502125b27..acebf9c92c04 100644
>> --- a/drivers/scsi/qla4xxx/ql4_os.c
>> +++ b/drivers/scsi/qla4xxx/ql4_os.c
>> @@ -1717,7 +1717,7 @@ qla4xxx_ep_connect(struct Scsi_Host *shost, struct 
>> sockaddr *dst_addr,
>>  }
>>  ha = iscsi_host_priv(shost);
>> -ep = iscsi_create_endpoint(sizeof(struct qla_endpoint));
>> +ep = iscsi_create_endpoint(shost, sizeof(struct qla_endpoint));
>>  if (!ep) {
>>  ret = -ENOMEM;
>>  retu

Re: Digest for open-iscsi@googlegroups.com - 1 update in 1 topic

[Lee Duncan]

This links to a proprietary iSCSI test suite. Not sure I approve of advertising 
here.

> On Feb 10, 2023, at 11:43 PM, open-iscsi@googlegroups.com wrote:
> 
> https://calsoftinc.com/blogs/2017/03/iscsi-introduction-steps-configure-iscsi-initiator-target.html

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/4EEF6C4C-D7C8-4C31-B391-353DD7150C4C%40gmail.com.

Re: [RFC 0/9] Make iscsid-kernel communications namespace-aware (resent)

['Lee Duncan' via open-iscsi]

[Resent to include all mailing lists]

I wanted to mention some issues I've discovered as part of testing this:

- Currently, only some sysfs entries are going to be different
  per namespace
- This means that the Configuration and Initiator Name are going to
  be common to all running daemons (this is /etc/iscsi)
- This also means that the Node database (and discovery DB,
  and interface DB) are common to all running daemons

I'm really not sure all running daemons should have the same initiator 
name. If we think of them as separate initiators, then this seems wrong.


Sharing the Node database may not be a good idea, either. This assumes 
that nodes discovered (and saved) from one namespace can actually be 
reached from other namespaces, but this may not be true. Having the Node 
DB and initiatorname shared means the different iscsid instances must 
cooperate with each other, else their requests can collide. Also, I can 
imagine situations where different daemons may want to set different 
configuration values. Currently they cannot.


On 2/8/23 09:40, Lee Duncan wrote:

From: Lee Duncan 

This is a request for comment on a set of patches that
modify the kernel iSCSI initiator communications so that
they are namespace-aware. The goal is to allow multiple
iSCSI daemon (iscsid) to run at once as long as they
are in separate namespaces, and so that iscsid can
run in containers.

Comments and suggestions are more than welcome. I do not
expect that this code is production-ready yet, and
networking isn't my strongest suit (yet).

These patches were originally posted in 2015 by Chris
Leech. There were some issues at the time about how
to handle namespaces going away. I hope to address
any issues raised with this patchset and then
to merge these changes upstream to address working
in working in containers.

My contribution thus far has been to update these patches
to work with the current upstream kernel.

Chris Leech/Lee Duncan (9):
   iscsi: create per-net iscsi netlink kernel sockets
   iscsi: associate endpoints with a host
   iscsi: sysfs filtering by network namespace
   iscsi: make all iSCSI netlink multicast namespace aware
   iscsi: set netns for iscsi_tcp hosts
   iscsi: check net namespace for all iscsi lookup
   iscsi: convert flashnode devices from bus to class
   iscsi: rename iscsi_bus_flash_* to iscsi_flash_*
   iscsi: filter flashnode sysfs by net namespace

  drivers/infiniband/ulp/iser/iscsi_iser.c |   7 +-
  drivers/scsi/be2iscsi/be_iscsi.c |   6 +-
  drivers/scsi/bnx2i/bnx2i_iscsi.c |   6 +-
  drivers/scsi/cxgbi/libcxgbi.c|   6 +-
  drivers/scsi/iscsi_tcp.c |   7 +
  drivers/scsi/qedi/qedi_iscsi.c   |   6 +-
  drivers/scsi/qla4xxx/ql4_os.c|  64 +--
  drivers/scsi/scsi_transport_iscsi.c  | 625 ---
  include/scsi/scsi_transport_iscsi.h  |  63 ++-
  9 files changed, 537 insertions(+), 253 deletions(-)



--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/f911472c-c4a1-27ee-8671-037f330096f0%40suse.com.

[RFC PATCH 6/9] iscsi: check net namespace for all iscsi lookup

[Lee Duncan]

From: Lee Duncan 

All internal lookups of iSCSI transport objects need to be filtered by
net namespace.

Signed-off-by: Chris Leech 
Signed-off-by: Lee Duncan 
---
 drivers/infiniband/ulp/iser/iscsi_iser.c |   5 +-
 drivers/scsi/be2iscsi/be_iscsi.c |   4 +-
 drivers/scsi/bnx2i/bnx2i_iscsi.c |   4 +-
 drivers/scsi/cxgbi/libcxgbi.c|   4 +-
 drivers/scsi/qedi/qedi_iscsi.c   |   4 +-
 drivers/scsi/qla4xxx/ql4_os.c|   8 +-
 drivers/scsi/scsi_transport_iscsi.c  | 202 ++-
 include/scsi/scsi_transport_iscsi.h  |   5 +-
 8 files changed, 149 insertions(+), 87 deletions(-)

diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c 
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index d38c909b462f..348bafb55e51 100644
--- a/drivers/infiniband/ulp/iser/iscsi_iser.c
+++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
@@ -456,15 +456,18 @@ static int iscsi_iser_conn_bind(struct iscsi_cls_session 
*cls_session,
struct iscsi_conn *conn = cls_conn->dd_data;
struct iser_conn *iser_conn;
struct iscsi_endpoint *ep;
+   struct net *net;
int error;
 
error = iscsi_conn_bind(cls_session, cls_conn, is_leading);
if (error)
return error;
 
+
/* the transport ep handle comes from user space so it must be
 * verified against the global ib connections list */
-   ep = iscsi_lookup_endpoint(transport_eph);
+   net = iscsi_sess_net(cls_session);
+   ep = iscsi_lookup_endpoint(net, transport_eph);
if (!ep) {
iser_err("can't bind eph %llx\n",
 (unsigned long long)transport_eph);
diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index c893d193f5ef..10329ed6a9a8 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -183,8 +183,10 @@ int beiscsi_conn_bind(struct iscsi_cls_session 
*cls_session,
struct iscsi_endpoint *ep;
uint16_t cri_index;
int rc = 0;
+   struct net *net;
 
-   ep = iscsi_lookup_endpoint(transport_fd);
+   net = iscsi_sess_net(cls_session);
+   ep = iscsi_lookup_endpoint(net, transport_fd);
if (!ep)
return -EINVAL;
 
diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
index ac63e93e07c6..e889c5585c87 100644
--- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
+++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
@@ -1411,9 +1411,11 @@ static int bnx2i_conn_bind(struct iscsi_cls_session 
*cls_session,
struct bnx2i_hba *hba = iscsi_host_priv(shost);
struct bnx2i_endpoint *bnx2i_ep;
struct iscsi_endpoint *ep;
+   struct net *net;
int ret_code;
 
-   ep = iscsi_lookup_endpoint(transport_fd);
+   net = iscsi_sess_net(cls_session);
+   ep = iscsi_lookup_endpoint(net, transport_fd);
if (!ep)
return -EINVAL;
/*
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index 94edf8e1fb0c..b492b57dbb2a 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -2676,9 +2676,11 @@ int cxgbi_bind_conn(struct iscsi_cls_session 
*cls_session,
struct iscsi_endpoint *ep;
struct cxgbi_endpoint *cep;
struct cxgbi_sock *csk;
+   struct net *net;
int err;
 
-   ep = iscsi_lookup_endpoint(transport_eph);
+   net = iscsi_sess_net(cls_session);
+   ep = iscsi_lookup_endpoint(net, transport_eph);
if (!ep)
return -EINVAL;
 
diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
index 4baf1dbb8e92..fc3406e6f82c 100644
--- a/drivers/scsi/qedi/qedi_iscsi.c
+++ b/drivers/scsi/qedi/qedi_iscsi.c
@@ -389,8 +389,10 @@ static int qedi_conn_bind(struct iscsi_cls_session 
*cls_session,
struct qedi_endpoint *qedi_ep;
struct iscsi_endpoint *ep;
int rc = 0;
+   struct net *net;
 
-   ep = iscsi_lookup_endpoint(transport_fd);
+   net = iscsi_sess_net(cls_session);
+   ep = iscsi_lookup_endpoint(net, transport_fd);
if (!ep)
return -EINVAL;
 
diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index acebf9c92c04..390b89bdec8f 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -3217,6 +3217,7 @@ static int qla4xxx_conn_bind(struct iscsi_cls_session 
*cls_session,
struct ddb_entry *ddb_entry;
struct scsi_qla_host *ha;
struct iscsi_session *sess;
+   struct net *net;
 
sess = cls_session->dd_data;
ddb_entry = sess->dd_data;
@@ -3225,11 +3226,12 @@ static int qla4xxx_conn_bind(struct iscsi_cls_session 
*cls_session,
DEBUG2(ql4_printk(KERN_INFO, ha, "%s: sid = %d, cid = %d\n", __func__,
  cls_session->sid, cls_conn->cid));
 
-   if (iscsi_conn_bind(cls_session, cls_conn, is_leading))
-  

[RFC PATCH 8/9] iscsi: rename iscsi_bus_flash_* to iscsi_flash_*

[Lee Duncan]

From: Lee Duncan 

These are cleanups after the bus to class conversion
for flashnode devices.

Signed-off-by: Chris Leech 
Signed-off-by: Lee Duncan 
---
 drivers/scsi/qla4xxx/ql4_os.c   |  52 +++---
 drivers/scsi/scsi_transport_iscsi.c | 102 ++--
 include/scsi/scsi_transport_iscsi.h |  48 ++---
 3 files changed, 102 insertions(+), 100 deletions(-)

diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index 18e382b6be18..8af6847773e3 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -168,20 +168,20 @@ static int qla4xxx_host_reset(struct Scsi_Host *shost, 
int reset_type);
  * iSCSI Flash DDB sysfs entry points
  */
 static int
-qla4xxx_sysfs_ddb_set_param(struct iscsi_bus_flash_session *fnode_sess,
-   struct iscsi_bus_flash_conn *fnode_conn,
+qla4xxx_sysfs_ddb_set_param(struct iscsi_flash_session *fnode_sess,
+   struct iscsi_flash_conn *fnode_conn,
void *data, int len);
 static int
-qla4xxx_sysfs_ddb_get_param(struct iscsi_bus_flash_session *fnode_sess,
+qla4xxx_sysfs_ddb_get_param(struct iscsi_flash_session *fnode_sess,
int param, char *buf);
 static int qla4xxx_sysfs_ddb_add(struct Scsi_Host *shost, const char *buf,
 int len);
 static int
-qla4xxx_sysfs_ddb_delete(struct iscsi_bus_flash_session *fnode_sess);
-static int qla4xxx_sysfs_ddb_login(struct iscsi_bus_flash_session *fnode_sess,
-  struct iscsi_bus_flash_conn *fnode_conn);
-static int qla4xxx_sysfs_ddb_logout(struct iscsi_bus_flash_session *fnode_sess,
-   struct iscsi_bus_flash_conn *fnode_conn);
+qla4xxx_sysfs_ddb_delete(struct iscsi_flash_session *fnode_sess);
+static int qla4xxx_sysfs_ddb_login(struct iscsi_flash_session *fnode_sess,
+  struct iscsi_flash_conn *fnode_conn);
+static int qla4xxx_sysfs_ddb_logout(struct iscsi_flash_session *fnode_sess,
+   struct iscsi_flash_conn *fnode_conn);
 static int qla4xxx_sysfs_ddb_logout_sid(struct iscsi_cls_session *cls_sess);
 
 static struct qla4_8xxx_legacy_intr_set legacy_intr[] =
@@ -3494,8 +3494,8 @@ static int qla4xxx_task_xmit(struct iscsi_task *task)
return -ENOSYS;
 }
 
-static int qla4xxx_copy_from_fwddb_param(struct iscsi_bus_flash_session *sess,
-struct iscsi_bus_flash_conn *conn,
+static int qla4xxx_copy_from_fwddb_param(struct iscsi_flash_session *sess,
+struct iscsi_flash_conn *conn,
 struct dev_db_entry *fw_ddb_entry)
 {
unsigned long options = 0;
@@ -3636,8 +3636,8 @@ static int qla4xxx_copy_from_fwddb_param(struct 
iscsi_bus_flash_session *sess,
return rc;
 }
 
-static int qla4xxx_copy_to_fwddb_param(struct iscsi_bus_flash_session *sess,
-  struct iscsi_bus_flash_conn *conn,
+static int qla4xxx_copy_to_fwddb_param(struct iscsi_flash_session *sess,
+  struct iscsi_flash_conn *conn,
   struct dev_db_entry *fw_ddb_entry)
 {
uint16_t options;
@@ -7183,7 +7183,7 @@ static void qla4xxx_build_new_nt_list(struct 
scsi_qla_host *ha,
  **/
 static int qla4xxx_sysfs_ddb_is_non_persistent(struct device *dev, void *data)
 {
-   struct iscsi_bus_flash_session *fnode_sess;
+   struct iscsi_flash_session *fnode_sess;
 
if (!iscsi_is_flashnode_session_dev(dev))
return 0;
@@ -7213,8 +7213,8 @@ static int qla4xxx_sysfs_ddb_tgt_create(struct 
scsi_qla_host *ha,
struct dev_db_entry *fw_ddb_entry,
uint16_t *idx, int user)
 {
-   struct iscsi_bus_flash_session *fnode_sess = NULL;
-   struct iscsi_bus_flash_conn *fnode_conn = NULL;
+   struct iscsi_flash_session *fnode_sess = NULL;
+   struct iscsi_flash_conn *fnode_conn = NULL;
int rc = QLA_ERROR;
 
fnode_sess = iscsi_create_flashnode_sess(ha->host, *idx,
@@ -7353,8 +7353,8 @@ static int qla4xxx_sysfs_ddb_add(struct Scsi_Host *shost, 
const char *buf,
  * This writes the contents of target ddb buffer to Flash with a valid cookie
  * value in order to make the ddb entry persistent.
  **/
-static int  qla4xxx_sysfs_ddb_apply(struct iscsi_bus_flash_session *fnode_sess,
-   struct iscsi_bus_flash_conn *fnode_conn)
+static int  qla4xxx_sysfs_ddb_apply(struct iscsi_flash_session *fnode_sess,
+   struct iscsi_flash_conn *fnode_conn)
 {
struct Scsi_Host *shost = iscsi_flash_session_to_shost(fnode_sess);
struct scsi_qla_host *ha = to_qla_host(shost);
@@ -7543,8 +7543,8 @@ static int qla4xxx_ddb_login_nt(struct scsi_qla_host 

[RFC PATCH 9/9] iscsi: filter flashnode sysfs by net namespace

[Lee Duncan]

From: Lee Duncan 

This finishes the net namespace support for flashnode sysfs devices.

Signed-off-by: Chris Leech 
Signed-off-by: Lee Duncan 
---
 drivers/scsi/scsi_transport_iscsi.c | 34 +
 include/scsi/scsi_transport_iscsi.h |  4 
 2 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index 13393c025ccb..9a176ea0d866 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -1268,8 +1268,42 @@ static int iscsi_is_flashnode_conn_dev(struct device 
*dev, void *data)
return dev->type == _flashnode_conn_dev_type;
 }
 
+static struct net *iscsi_flashnode_sess_net(struct iscsi_flash_session *f_sess)
+{
+   struct Scsi_Host *shost = iscsi_flash_session_to_shost(f_sess);
+   struct iscsi_cls_host *ihost = shost->shost_data;
+
+   return iscsi_host_net(ihost);
+}
+
+static struct net *iscsi_flashnode_conn_net(struct iscsi_flash_conn *f_conn)
+{
+   struct iscsi_flash_session *f_sess =
+   iscsi_flash_conn_to_flash_session(f_conn);
+
+   return iscsi_flashnode_sess_net(f_sess);
+}
+
+static const void *iscsi_flashnode_namespace(const struct device *dev)
+{
+   struct iscsi_flash_conn *f_conn;
+   struct iscsi_flash_session *f_sess;
+   struct device *dev_tmp = (struct device *)dev;
+
+   if (iscsi_is_flashnode_conn_dev(dev_tmp, NULL)) {
+   f_conn = iscsi_dev_to_flash_conn(dev);
+   return iscsi_flashnode_conn_net(f_conn);
+   } else if (iscsi_is_flashnode_session_dev(dev_tmp)) {
+   f_sess = iscsi_dev_to_flash_session(dev);
+   return iscsi_flashnode_sess_net(f_sess);
+   }
+   return NULL;
+}
+
 static struct class iscsi_flashnode = {
.name = "iscsi_flashnode",
+   .ns_type = _ns_type_operations,
+   .namespace = iscsi_flashnode_namespace,
 };
 
 /**
diff --git a/include/scsi/scsi_transport_iscsi.h 
b/include/scsi/scsi_transport_iscsi.h
index d03d9eb5707b..0c3fd690ecf8 100644
--- a/include/scsi/scsi_transport_iscsi.h
+++ b/include/scsi/scsi_transport_iscsi.h
@@ -504,8 +504,6 @@ extern void
 iscsi_destroy_flashnode_sess(struct iscsi_flash_session *fnode_sess);
 
 extern void iscsi_destroy_all_flashnode(struct Scsi_Host *shost);
-extern int iscsi_flashnode_bus_match(struct device *dev,
-struct device_driver *drv);
 extern struct device *
 iscsi_find_flashnode_sess(struct Scsi_Host *shost, void *data,
  int (*fn)(struct device *dev, void *data));
@@ -514,8 +512,6 @@ iscsi_find_flashnode_conn(struct iscsi_flash_session 
*fnode_sess);
 
 extern bool iscsi_is_flashnode_session_dev(struct device *dev);
 
-extern bool iscsi_is_flashnode_session_dev(struct device *dev);
-
 extern char *
 iscsi_get_ipaddress_state_name(enum iscsi_ipaddress_state port_state);
 extern char *iscsi_get_router_state_name(enum iscsi_router_state router_state);
-- 
2.39.1

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/283ecc31424b7f5e8e3dd68aa2283fcd109de145.1675876736.git.lduncan%40suse.com.

[RFC PATCH 4/9] iscsi: make all iSCSI netlink multicast namespace aware

[Lee Duncan]

From: Lee Duncan 

Make use of the per-net netlink sockets. Responses are sent back on the
same socket/namespace the request was received on.  Async events are
reported on the socket/namespace stored in the iscsi_cls_host associated
with the event.

Signed-off-by: Chris Leech 
Signed-off-by: Lee Duncan 
---
 drivers/scsi/scsi_transport_iscsi.c | 92 +++--
 1 file changed, 60 insertions(+), 32 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index 2e2b291bce41..230b43d34c5f 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2653,8 +2653,8 @@ iscsi_if_transport_lookup(struct iscsi_transport *tt)
 }
 
 static int
-iscsi_multicast_netns(struct net *net, struct sk_buff *skb,
- uint32_t group, gfp_t gfp)
+iscsi_multicast_skb(struct net *net, struct sk_buff *skb,
+   uint32_t group, gfp_t gfp)
 {
struct sock *nls;
struct iscsi_net *isn;
@@ -2665,17 +2665,10 @@ iscsi_multicast_netns(struct net *net, struct sk_buff 
*skb,
 }
 
 static int
-iscsi_multicast_skb(struct sk_buff *skb, uint32_t group, gfp_t gfp)
-{
-   return iscsi_multicast_netns(_net, skb, group, gfp);
-}
-
-static int
-iscsi_unicast_skb(struct sk_buff *skb, u32 portid)
+iscsi_unicast_skb(struct net *net, struct sk_buff *skb, u32 portid)
 {
struct sock *nls;
struct iscsi_net *isn;
-   struct net *net = _net;
 
isn = net_generic(net, iscsi_net_id);
nls = isn->nls;
@@ -2690,6 +2683,7 @@ int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct 
iscsi_hdr *hdr,
struct iscsi_uevent *ev;
char *pdu;
struct iscsi_internal *priv;
+   struct net *net;
int len = nlmsg_total_size(sizeof(*ev) + sizeof(struct iscsi_hdr) +
   data_size);
 
@@ -2716,7 +2710,8 @@ int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct 
iscsi_hdr *hdr,
memcpy(pdu, hdr, sizeof(struct iscsi_hdr));
memcpy(pdu + sizeof(struct iscsi_hdr), data, data_size);
 
-   return iscsi_multicast_skb(skb, ISCSI_NL_GRP_ISCSID, GFP_ATOMIC);
+   net = iscsi_conn_net(conn);
+   return iscsi_multicast_skb(net, skb, ISCSI_NL_GRP_ISCSID, GFP_ATOMIC);
 }
 EXPORT_SYMBOL_GPL(iscsi_recv_pdu);
 
@@ -2727,6 +2722,7 @@ int iscsi_offload_mesg(struct Scsi_Host *shost,
struct nlmsghdr *nlh;
struct sk_buff *skb;
struct iscsi_uevent *ev;
+   struct net *net;
int len = nlmsg_total_size(sizeof(*ev) + data_size);
 
skb = alloc_skb(len, GFP_ATOMIC);
@@ -2751,7 +2747,8 @@ int iscsi_offload_mesg(struct Scsi_Host *shost,
 
memcpy((char *)ev + sizeof(*ev), data, data_size);
 
-   return iscsi_multicast_skb(skb, ISCSI_NL_GRP_UIP, GFP_ATOMIC);
+   net = iscsi_host_net(shost->shost_data);
+   return iscsi_multicast_skb(net, skb, ISCSI_NL_GRP_UIP, GFP_ATOMIC);
 }
 EXPORT_SYMBOL_GPL(iscsi_offload_mesg);
 
@@ -2761,6 +2758,7 @@ void iscsi_conn_error_event(struct iscsi_cls_conn *conn, 
enum iscsi_err error)
struct sk_buff  *skb;
struct iscsi_uevent *ev;
struct iscsi_internal *priv;
+   struct net *net;
int len = nlmsg_total_size(sizeof(*ev));
unsigned long flags;
int state;
@@ -2808,7 +2806,8 @@ void iscsi_conn_error_event(struct iscsi_cls_conn *conn, 
enum iscsi_err error)
ev->r.connerror.cid = conn->cid;
ev->r.connerror.sid = iscsi_conn_get_sid(conn);
 
-   iscsi_multicast_skb(skb, ISCSI_NL_GRP_ISCSID, GFP_ATOMIC);
+   net = iscsi_conn_net(conn);
+   iscsi_multicast_skb(net, skb, ISCSI_NL_GRP_ISCSID, GFP_ATOMIC);
 
iscsi_cls_conn_printk(KERN_INFO, conn, "detected conn error (%d)\n",
  error);
@@ -2822,6 +2821,7 @@ void iscsi_conn_login_event(struct iscsi_cls_conn *conn,
struct sk_buff  *skb;
struct iscsi_uevent *ev;
struct iscsi_internal *priv;
+   struct net *net;
int len = nlmsg_total_size(sizeof(*ev));
 
priv = iscsi_if_transport_lookup(conn->transport);
@@ -2842,7 +2842,9 @@ void iscsi_conn_login_event(struct iscsi_cls_conn *conn,
ev->r.conn_login.state = state;
ev->r.conn_login.cid = conn->cid;
ev->r.conn_login.sid = iscsi_conn_get_sid(conn);
-   iscsi_multicast_skb(skb, ISCSI_NL_GRP_ISCSID, GFP_ATOMIC);
+
+   net = iscsi_conn_net(conn);
+   iscsi_multicast_skb(net, skb, ISCSI_NL_GRP_ISCSID, GFP_ATOMIC);
 
iscsi_cls_conn_printk(KERN_INFO, conn, "detected conn login (%d)\n",
  state);
@@ -2853,11 +2855,17 @@ void iscsi_post_host_event(uint32_t host_no, struct 
iscsi_transport *transport,
   enum iscsi_host_event_code code, uint32_t data_size,
   uint8_t *data)
 {
+   struct Scsi_Host *shost;
+   struct net *net;
struct nlmsghdr

[RFC PATCH 5/9] iscsi: set netns for iscsi_tcp hosts

[Lee Duncan]

From: Lee Duncan 

This lets iscsi_tcp operate in multiple namespaces.  It uses current
during session creation to find the net namespace, but it might be
better to manage to pass it along from the iscsi netlink socket.

Signed-off-by: Chris Leech 
Signed-off-by: Lee Duncan 
---
 drivers/scsi/iscsi_tcp.c| 7 +++
 drivers/scsi/scsi_transport_iscsi.c | 7 ++-
 include/scsi/scsi_transport_iscsi.h | 1 +
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 0454d94e8cf0..22e7a5c93627 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -1069,6 +1069,11 @@ static int iscsi_sw_tcp_slave_configure(struct 
scsi_device *sdev)
return 0;
 }
 
+static struct net *iscsi_sw_tcp_netns(struct Scsi_Host *shost)
+{
+   return current->nsproxy->net_ns;
+}
+
 static struct scsi_host_template iscsi_sw_tcp_sht = {
.module = THIS_MODULE,
.name   = "iSCSI Initiator over TCP/IP",
@@ -1124,6 +1129,8 @@ static struct iscsi_transport iscsi_sw_tcp_transport = {
.alloc_pdu  = iscsi_sw_tcp_pdu_alloc,
/* recovery */
.session_recovery_timedout = iscsi_session_recovery_timedout,
+   /* net namespace */
+   .get_netns  = iscsi_sw_tcp_netns,
 };
 
 static int __init iscsi_sw_tcp_init(void)
diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index 230b43d34c5f..996a9abfa1f5 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -1600,10 +1600,15 @@ static int iscsi_setup_host(struct transport_container 
*tc, struct device *dev,
 {
struct Scsi_Host *shost = dev_to_shost(dev);
struct iscsi_cls_host *ihost = shost->shost_data;
+   struct iscsi_internal *priv = to_iscsi_internal(shost->transportt);
+   struct iscsi_transport *transport = priv->iscsi_transport;
 
memset(ihost, 0, sizeof(*ihost));
mutex_init(>mutex);
-   ihost->netns = _net;
+   if (transport->get_netns)
+   ihost->netns = transport->get_netns(shost);
+   else
+   ihost->netns = _net;
 
iscsi_bsg_host_add(shost, ihost);
/* ignore any bsg add error - we just can't do sgio */
diff --git a/include/scsi/scsi_transport_iscsi.h 
b/include/scsi/scsi_transport_iscsi.h
index af0c5a15f316..f8885d0c37d8 100644
--- a/include/scsi/scsi_transport_iscsi.h
+++ b/include/scsi/scsi_transport_iscsi.h
@@ -156,6 +156,7 @@ struct iscsi_transport {
int (*logout_flashnode_sid) (struct iscsi_cls_session *cls_sess);
int (*get_host_stats) (struct Scsi_Host *shost, char *buf, int len);
u8 (*check_protection)(struct iscsi_task *task, sector_t *sector);
+   struct net *(*get_netns)(struct Scsi_Host *shost);
 };
 
 /*
-- 
2.39.1

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/566c527d12f6ed56eeb40952fef7431a0ccdc78f.1675876735.git.lduncan%40suse.com.

[RFC PATCH 7/9] iscsi: convert flashnode devices from bus to class

[Lee Duncan]

From: Lee Duncan 

The flashnode session and connection devices should be filtered by net
namespace along with the iscsi_host, but we can't do that with a bus
device.  As these don't use any of the bus matching functionality, they
make more sense as a class device anyway.

Signed-off-by: Chris Leech 
Signed-off-by: Lee Duncan 
---
 drivers/scsi/qla4xxx/ql4_os.c   |  2 +-
 drivers/scsi/scsi_transport_iscsi.c | 36 -
 include/scsi/scsi_transport_iscsi.h |  2 ++
 3 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index 390b89bdec8f..18e382b6be18 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -7185,7 +7185,7 @@ static int qla4xxx_sysfs_ddb_is_non_persistent(struct 
device *dev, void *data)
 {
struct iscsi_bus_flash_session *fnode_sess;
 
-   if (!iscsi_flashnode_bus_match(dev, NULL))
+   if (!iscsi_is_flashnode_session_dev(dev))
return 0;
 
fnode_sess = iscsi_dev_to_flash_session(dev);
diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index 008adde4dc51..c065763b1fc6 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -1060,6 +1060,12 @@ static const struct device_type 
iscsi_flashnode_sess_dev_type = {
.release = iscsi_flashnode_sess_release,
 };
 
+bool iscsi_is_flashnode_session_dev(struct device *dev)
+{
+   return dev->type == _flashnode_sess_dev_type;
+}
+EXPORT_SYMBOL_GPL(iscsi_is_flashnode_session_dev);
+
 /* flash node connection attrs show */
 #define iscsi_flashnode_conn_attr_show(type, name, param)  \
 static ssize_t \
@@ -1246,20 +1252,8 @@ static const struct device_type 
iscsi_flashnode_conn_dev_type = {
.release = iscsi_flashnode_conn_release,
 };
 
-static struct bus_type iscsi_flashnode_bus;
-
-int iscsi_flashnode_bus_match(struct device *dev,
-struct device_driver *drv)
-{
-   if (dev->bus == _flashnode_bus)
-   return 1;
-   return 0;
-}
-EXPORT_SYMBOL_GPL(iscsi_flashnode_bus_match);
-
-static struct bus_type iscsi_flashnode_bus = {
+static struct class iscsi_flashnode_bus = {
.name = "iscsi_flashnode",
-   .match = _flashnode_bus_match,
 };
 
 /**
@@ -1290,7 +1284,7 @@ iscsi_create_flashnode_sess(struct Scsi_Host *shost, int 
index,
fnode_sess->transport = transport;
fnode_sess->target_id = index;
fnode_sess->dev.type = _flashnode_sess_dev_type;
-   fnode_sess->dev.bus = _flashnode_bus;
+   fnode_sess->dev.class = _flashnode_bus;
fnode_sess->dev.parent = >shost_gendev;
dev_set_name(_sess->dev, "flashnode_sess-%u:%u",
 shost->host_no, index);
@@ -1338,7 +1332,7 @@ iscsi_create_flashnode_conn(struct Scsi_Host *shost,
 
fnode_conn->transport = transport;
fnode_conn->dev.type = _flashnode_conn_dev_type;
-   fnode_conn->dev.bus = _flashnode_bus;
+   fnode_conn->dev.class = _flashnode_bus;
fnode_conn->dev.parent = _sess->dev;
dev_set_name(_conn->dev, "flashnode_conn-%u:%u:0",
 shost->host_no, fnode_sess->target_id);
@@ -1371,7 +1365,7 @@ EXPORT_SYMBOL_GPL(iscsi_create_flashnode_conn);
  */
 static int iscsi_is_flashnode_conn_dev(struct device *dev, void *data)
 {
-   return dev->bus == _flashnode_bus;
+   return dev->type == _flashnode_conn_dev_type;
 }
 
 static int iscsi_destroy_flashnode_conn(struct iscsi_bus_flash_conn 
*fnode_conn)
@@ -1385,7 +1379,7 @@ static int flashnode_match_index(struct device *dev, void 
*data)
struct iscsi_bus_flash_session *fnode_sess = NULL;
int ret = 0;
 
-   if (!iscsi_flashnode_bus_match(dev, NULL))
+   if (dev->type != _flashnode_sess_dev_type)
goto exit_match_index;
 
fnode_sess = iscsi_dev_to_flash_session(dev);
@@ -1491,7 +1485,7 @@ EXPORT_SYMBOL_GPL(iscsi_destroy_flashnode_sess);
 
 static int iscsi_iter_destroy_flashnode_fn(struct device *dev, void *data)
 {
-   if (!iscsi_flashnode_bus_match(dev, NULL))
+   if (dev->type != _flashnode_sess_dev_type)
return 0;
 
iscsi_destroy_flashnode_sess(iscsi_dev_to_flash_session(dev));
@@ -5200,7 +5194,7 @@ static __init int iscsi_transport_init(void)
if (err)
goto unregister_conn_class;
 
-   err = bus_register(_flashnode_bus);
+   err = class_register(_flashnode_bus);
if (err)
goto unregister_session_class;
 
@@ -5223,7 +5217,7 @@ static __init int iscsi_transport_init(void)
 unregister_pernet_subsys:
unregister_pernet_subsys(_net_ops);
 unregister_flashnode_bus:
-   bus_unregister(_flashnode_bus);
+   class_un

[RFC PATCH 3/9] iscsi: sysfs filtering by network namespace

[Lee Duncan]

From: Lee Duncan 

This makes the iscsi_host, iscsi_session, iscsi_connection, iscsi_iface,
and iscsi_endpoint transport class devices only visible in sysfs under a
matching network namespace.  The network namespace for all of these
objects is tracked in the iscsi_cls_host structure.

Signed-off-by: Chris Leech 
Signed-off-by: Lee Duncan 
---
 drivers/scsi/scsi_transport_iscsi.c | 124 
 include/scsi/scsi_transport_iscsi.h |   1 +
 2 files changed, 110 insertions(+), 15 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index 86bafdb862a5..2e2b291bce41 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -181,9 +181,31 @@ static void iscsi_endpoint_release(struct device *dev)
kfree(ep);
 }
 
+static struct net *iscsi_host_net(struct iscsi_cls_host *ihost)
+{
+   return ihost->netns;
+}
+
+static struct net *iscsi_endpoint_net(struct iscsi_endpoint *ep)
+{
+   struct Scsi_Host *shost = iscsi_endpoint_to_shost(ep);
+   struct iscsi_cls_host *ihost = shost->shost_data;
+
+   return iscsi_host_net(ihost);
+}
+
+static const void *iscsi_endpoint_namespace(const struct device *dev)
+{
+   struct iscsi_endpoint *ep = iscsi_dev_to_endpoint(dev);
+
+   return iscsi_endpoint_net(ep);
+}
+
 static struct class iscsi_endpoint_class = {
.name = "iscsi_endpoint",
.dev_release = iscsi_endpoint_release,
+   .ns_type = _ns_type_operations,
+   .namespace = iscsi_endpoint_namespace,
 };
 
 static ssize_t
@@ -308,10 +330,26 @@ static void iscsi_iface_release(struct device *dev)
put_device(parent);
 }
 
+static struct net *iscsi_iface_net(struct iscsi_iface *iface)
+{
+   struct Scsi_Host *shost = iscsi_iface_to_shost(iface);
+   struct iscsi_cls_host *ihost = shost->shost_data;
+
+   return iscsi_host_net(ihost);
+}
+
+static const void *iscsi_iface_namespace(const struct device *dev)
+{
+   struct iscsi_iface *iface = iscsi_dev_to_iface(dev);
+
+   return iscsi_iface_net(iface);
+}
 
 static struct class iscsi_iface_class = {
.name = "iscsi_iface",
.dev_release = iscsi_iface_release,
+   .ns_type = _ns_type_operations,
+   .namespace = iscsi_iface_namespace,
 };
 
 #define ISCSI_IFACE_ATTR(_prefix, _name, _mode, _show, _store) \
@@ -1565,6 +1603,7 @@ static int iscsi_setup_host(struct transport_container 
*tc, struct device *dev,
 
memset(ihost, 0, sizeof(*ihost));
mutex_init(>mutex);
+   ihost->netns = _net;
 
iscsi_bsg_host_add(shost, ihost);
/* ignore any bsg add error - we just can't do sgio */
@@ -1582,23 +1621,78 @@ static int iscsi_remove_host(struct transport_container 
*tc,
return 0;
 }
 
-static DECLARE_TRANSPORT_CLASS(iscsi_host_class,
-  "iscsi_host",
-  iscsi_setup_host,
-  iscsi_remove_host,
-  NULL);
+#define DECLARE_TRANSPORT_CLASS_NS(cls, nm, su, rm, cfg, ns, nslookup) \
+struct transport_class cls = { \
+   .class = {  \
+   .name = nm, \
+   .ns_type = ns,  \
+   .namespace = nslookup,  \
+   },  \
+   .setup = su,\
+   .remove = rm,   \
+   .configure = cfg,   \
+}
+
+static const void *iscsi_host_namespace(const struct device *dev)
+{
+   struct Scsi_Host *shost = transport_class_to_shost(dev);
+   struct iscsi_cls_host *ihost = shost->shost_data;
+
+   return iscsi_host_net(ihost);
+}
+
+static DECLARE_TRANSPORT_CLASS_NS(iscsi_host_class,
+ "iscsi_host",
+ iscsi_setup_host,
+ iscsi_remove_host,
+ NULL,
+ _ns_type_operations,
+ iscsi_host_namespace);
 
-static DECLARE_TRANSPORT_CLASS(iscsi_session_class,
-  "iscsi_session",
-  NULL,
-  NULL,
-  NULL);
+static struct net *iscsi_sess_net(struct iscsi_cls_session *cls_session)
+{
+   struct Scsi_Host *shost = iscsi_session_to_shost(cls_session);
+   struct iscsi_cls_host *ihost = shost->shost_data;
+
+   return iscsi_host_net(ihost);
+}
+
+static const void *iscsi_sess_namespace(const struct device *dev)
+{
+  

[RFC PATCH 1/9] iscsi: create per-net iscsi netlink kernel sockets

[Lee Duncan]

From: Lee Duncan 

Prepare iSCSI netlink to operate in multiple namespaces.

Signed-off-by: Chris Leech 
Signed-off-by: Lee Duncan 
---
 drivers/scsi/scsi_transport_iscsi.c | 73 +
 1 file changed, 63 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index b9b97300e3b3..be69cea9c6f8 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -1597,7 +1599,11 @@ static DECLARE_TRANSPORT_CLASS(iscsi_connection_class,
   NULL,
   NULL);
 
-static struct sock *nls;
+struct iscsi_net {
+   struct sock *nls;
+};
+
+static int iscsi_net_id __read_mostly;
 static DEFINE_MUTEX(rx_queue_mutex);
 
 static LIST_HEAD(sesslist);
@@ -2552,14 +2558,32 @@ iscsi_if_transport_lookup(struct iscsi_transport *tt)
 }
 
 static int
-iscsi_multicast_skb(struct sk_buff *skb, uint32_t group, gfp_t gfp)
+iscsi_multicast_netns(struct net *net, struct sk_buff *skb,
+ uint32_t group, gfp_t gfp)
 {
+   struct sock *nls;
+   struct iscsi_net *isn;
+
+   isn = net_generic(net, iscsi_net_id);
+   nls = isn->nls;
return nlmsg_multicast(nls, skb, 0, group, gfp);
 }
 
+static int
+iscsi_multicast_skb(struct sk_buff *skb, uint32_t group, gfp_t gfp)
+{
+   return iscsi_multicast_netns(_net, skb, group, gfp);
+}
+
 static int
 iscsi_unicast_skb(struct sk_buff *skb, u32 portid)
 {
+   struct sock *nls;
+   struct iscsi_net *isn;
+   struct net *net = _net;
+
+   isn = net_generic(net, iscsi_net_id);
+   nls = isn->nls;
return nlmsg_unicast(nls, skb, portid);
 }
 
@@ -4937,13 +4961,42 @@ void iscsi_dbg_trace(void (*trace)(struct device *dev, 
struct va_format *),
 }
 EXPORT_SYMBOL_GPL(iscsi_dbg_trace);
 
-static __init int iscsi_transport_init(void)
+static int __net_init iscsi_net_init(struct net *net)
 {
-   int err;
+   struct sock *nls;
+   struct iscsi_net *isn;
struct netlink_kernel_cfg cfg = {
.groups = 1,
.input  = iscsi_if_rx,
};
+
+   nls = netlink_kernel_create(net, NETLINK_ISCSI, );
+   if (!nls)
+   return -ENOMEM;
+   isn = net_generic(net, iscsi_net_id);
+   isn->nls = nls;
+   return 0;
+}
+
+static void __net_exit iscsi_net_exit(struct net *net)
+{
+   struct iscsi_net *isn;
+
+   isn = net_generic(net, iscsi_net_id);
+   netlink_kernel_release(isn->nls);
+   isn->nls = NULL;
+}
+
+static struct pernet_operations iscsi_net_ops = {
+   .init = iscsi_net_init,
+   .exit = iscsi_net_exit,
+   .id   = _net_id,
+   .size = sizeof(struct iscsi_net),
+};
+
+static __init int iscsi_transport_init(void)
+{
+   int err;
printk(KERN_INFO "Loading iSCSI transport class v%s.\n",
ISCSI_TRANSPORT_VERSION);
 
@@ -4977,8 +5030,8 @@ static __init int iscsi_transport_init(void)
if (err)
goto unregister_session_class;
 
-   nls = netlink_kernel_create(_net, NETLINK_ISCSI, );
-   if (!nls) {
+   err = register_pernet_subsys(_net_ops);
+   if (err) {
err = -ENOBUFS;
goto unregister_flashnode_bus;
}
@@ -4988,13 +5041,13 @@ static __init int iscsi_transport_init(void)
"iscsi_conn_cleanup");
if (!iscsi_conn_cleanup_workq) {
err = -ENOMEM;
-   goto release_nls;
+   goto unregister_pernet_subsys;
}
 
return 0;
 
-release_nls:
-   netlink_kernel_release(nls);
+unregister_pernet_subsys:
+   unregister_pernet_subsys(_net_ops);
 unregister_flashnode_bus:
bus_unregister(_flashnode_bus);
 unregister_session_class:
@@ -5015,7 +5068,7 @@ static __init int iscsi_transport_init(void)
 static void __exit iscsi_transport_exit(void)
 {
destroy_workqueue(iscsi_conn_cleanup_workq);
-   netlink_kernel_release(nls);
+   unregister_pernet_subsys(_net_ops);
bus_unregister(_flashnode_bus);
transport_class_unregister(_connection_class);
transport_class_unregister(_session_class);
-- 
2.39.1

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/95df16a252bc2c9f0e7fba667d2f542814c9b91b.1675876733.git.lduncan%40suse.com.

[RFC PATCH 2/9] iscsi: associate endpoints with a host

[Lee Duncan]

From: Lee Duncan 

Right now the iscsi_endpoint is only linked to a connection once that
connection has been established.  For net namespace filtering of the
sysfs objects, associate an endpoint with the host that it was
allocated for when it is created.

Signed-off-by: Chris Leech 
Signed-off-by: Lee Duncan 
---
 drivers/infiniband/ulp/iser/iscsi_iser.c | 2 +-
 drivers/scsi/be2iscsi/be_iscsi.c | 2 +-
 drivers/scsi/bnx2i/bnx2i_iscsi.c | 2 +-
 drivers/scsi/cxgbi/libcxgbi.c| 2 +-
 drivers/scsi/qedi/qedi_iscsi.c   | 2 +-
 drivers/scsi/qla4xxx/ql4_os.c| 2 +-
 drivers/scsi/scsi_transport_iscsi.c  | 3 ++-
 include/scsi/scsi_transport_iscsi.h  | 6 +-
 8 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c 
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index 620ae5b2d80d..d38c909b462f 100644
--- a/drivers/infiniband/ulp/iser/iscsi_iser.c
+++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
@@ -802,7 +802,7 @@ static struct iscsi_endpoint *iscsi_iser_ep_connect(struct 
Scsi_Host *shost,
struct iser_conn *iser_conn;
struct iscsi_endpoint *ep;
 
-   ep = iscsi_create_endpoint(0);
+   ep = iscsi_create_endpoint(shost, 0);
if (!ep)
return ERR_PTR(-ENOMEM);
 
diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index 8aeaddc93b16..c893d193f5ef 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -1168,7 +1168,7 @@ beiscsi_ep_connect(struct Scsi_Host *shost, struct 
sockaddr *dst_addr,
return ERR_PTR(ret);
}
 
-   ep = iscsi_create_endpoint(sizeof(struct beiscsi_endpoint));
+   ep = iscsi_create_endpoint(shost, sizeof(struct beiscsi_endpoint));
if (!ep) {
ret = -ENOMEM;
return ERR_PTR(ret);
diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
index a3c800e04a2e..ac63e93e07c6 100644
--- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
+++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
@@ -384,7 +384,7 @@ static struct iscsi_endpoint *bnx2i_alloc_ep(struct 
bnx2i_hba *hba)
struct bnx2i_endpoint *bnx2i_ep;
u32 ec_div;
 
-   ep = iscsi_create_endpoint(sizeof(*bnx2i_ep));
+   ep = iscsi_create_endpoint(hba->shost, sizeof(*bnx2i_ep));
if (!ep) {
printk(KERN_ERR "bnx2i: Could not allocate ep\n");
return NULL;
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index af281e271f88..94edf8e1fb0c 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -2926,7 +2926,7 @@ struct iscsi_endpoint *cxgbi_ep_connect(struct Scsi_Host 
*shost,
goto release_conn;
}
 
-   ep = iscsi_create_endpoint(sizeof(*cep));
+   ep = iscsi_create_endpoint(shost, sizeof(*cep));
if (!ep) {
err = -ENOMEM;
pr_info("iscsi alloc ep, OOM.\n");
diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
index 31ec429104e2..4baf1dbb8e92 100644
--- a/drivers/scsi/qedi/qedi_iscsi.c
+++ b/drivers/scsi/qedi/qedi_iscsi.c
@@ -931,7 +931,7 @@ qedi_ep_connect(struct Scsi_Host *shost, struct sockaddr 
*dst_addr,
return ERR_PTR(-ENXIO);
}
 
-   ep = iscsi_create_endpoint(sizeof(struct qedi_endpoint));
+   ep = iscsi_create_endpoint(shost, sizeof(struct qedi_endpoint));
if (!ep) {
QEDI_ERR(>dbg_ctx, "endpoint create fail\n");
ret = -ENOMEM;
diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index 005502125b27..acebf9c92c04 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -1717,7 +1717,7 @@ qla4xxx_ep_connect(struct Scsi_Host *shost, struct 
sockaddr *dst_addr,
}
 
ha = iscsi_host_priv(shost);
-   ep = iscsi_create_endpoint(sizeof(struct qla_endpoint));
+   ep = iscsi_create_endpoint(shost, sizeof(struct qla_endpoint));
if (!ep) {
ret = -ENOMEM;
return ERR_PTR(ret);
diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index be69cea9c6f8..86bafdb862a5 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -204,7 +204,7 @@ static struct attribute_group iscsi_endpoint_group = {
 };
 
 struct iscsi_endpoint *
-iscsi_create_endpoint(int dd_size)
+iscsi_create_endpoint(struct Scsi_Host *shost, int dd_size)
 {
struct iscsi_endpoint *ep;
int err, id;
@@ -230,6 +230,7 @@ iscsi_create_endpoint(int dd_size)
 
ep->id = id;
ep->dev.class = _endpoint_class;
+   ep->dev.parent = >shost_gendev;
dev_set_name(>dev, "ep-%d", id);
err = device_register(>dev);
 if (err)
diff --git a/include/scsi/scsi_transport_iscsi.h 
b/include/scs

[RFC 0/9] Make iscsid-kernel communications namespace-aware

[Lee Duncan]

From: Lee Duncan 

This is a request for comment on a set of patches that
modify the kernel iSCSI initiator communications so that
they are namespace-aware. The goal is to allow multiple
iSCSI daemon (iscsid) to run at once as long as they
are in separate namespaces, and so that iscsid can
run in containers.

Comments and suggestions are more than welcome. I do not
expect that this code is production-ready yet, and
networking isn't my strongest suit (yet).

These patches were originally posted in 2015 by Chris
Leech. There were some issues at the time about how
to handle namespaces going away. I hope to address
any issues raised with this patchset and then
to merge these changes upstream to address working
in working in containers.

My contribution thus far has been to update these patches
to work with the current upstream kernel.

Chris Leech/Lee Duncan (9):
  iscsi: create per-net iscsi netlink kernel sockets
  iscsi: associate endpoints with a host
  iscsi: sysfs filtering by network namespace
  iscsi: make all iSCSI netlink multicast namespace aware
  iscsi: set netns for iscsi_tcp hosts
  iscsi: check net namespace for all iscsi lookup
  iscsi: convert flashnode devices from bus to class
  iscsi: rename iscsi_bus_flash_* to iscsi_flash_*
  iscsi: filter flashnode sysfs by net namespace

 drivers/infiniband/ulp/iser/iscsi_iser.c |   7 +-
 drivers/scsi/be2iscsi/be_iscsi.c |   6 +-
 drivers/scsi/bnx2i/bnx2i_iscsi.c |   6 +-
 drivers/scsi/cxgbi/libcxgbi.c|   6 +-
 drivers/scsi/iscsi_tcp.c |   7 +
 drivers/scsi/qedi/qedi_iscsi.c   |   6 +-
 drivers/scsi/qla4xxx/ql4_os.c|  64 +--
 drivers/scsi/scsi_transport_iscsi.c  | 625 ---
 include/scsi/scsi_transport_iscsi.h  |  63 ++-
 9 files changed, 537 insertions(+), 253 deletions(-)

-- 
2.39.1

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/cover.1675876731.git.lduncan%40suse.com.

Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

['Lee Duncan' via open-iscsi]

On 12/4/22 05:02, Wenchao Hao wrote:

On Thu, Dec 1, 2022 at 3:53 AM Lee Duncan  wrote:



...


Let me start by saying I agree with you now, that there *is* an issue.
But your test was flawed.

After you log into a target, changing the Node database does nothing.
The node database is only referenced with you login using it, e.g.
"iscsiadm -m node ... -l".

But even if you logged out and then back into the target, thereby using
the updated Node DB entries, it would not have worked.

For one thing, "iscsiadm -m session -u" just logs out of all sessions,
as far as I can see, based on testing and code inspection. So that is a
problem.

Note that the iscsi.service systemd service file on SLES does "not" do
that. It instead logs of of "manual" and "automatic" session, but only
ones that are listed in the Node database.

And as you pointed out, any knowledge iscsid has of existing sessions is
lost if the daemmon dies or is stopped, then restarted. At that point,
the only knowledge is has about each session is what it finds in sysfs.

I have done some testing with your new kernel change that adds a
"node_startup" sysfs string attribute to session data. I modified
open-iscsi to pass in the node startup value, and that's a good start.
The next step is adding a "startup" value in the session structure,
filling it in from sysfs (or current state), and refusing to logout out
of sesions that have this set to "onboot", which all sounds fairly
simple. I also want to test with "iscsiadm -m fw -l", which is what I
believe is used when booting from software iscsi (i.e. iBFT).

Have you already worked on the open-iscsi side of this? No reason for
duplicate development.

--
Lee Duncan



Sorry I missed this message, I have modified open-iscsi to work
with this sysfs interface. But I think we do not need this any more
because the safe logout can avoid disks being removed.

Checking holders and if disk is mounted before logout seems enough,
so ignore this discussion.

Thank you very much for your reply.


I have some philosophical issues with using safe_logout.

It is off by default, which implies to me that it has overhead. If I'm 
doing a lot of iscsi session start/stops, I don't want the overhead. 
Otherwise, why not just use it all the time.


Also, it only checks for mounts. What about if some process has the 
device open but isn't using it for a filesystem?


And since it has overhead, I'd rather just use it on root iscsi volumes. 
I have not had a single problem report from folks that have ended a 
session by accident that is mounted on. Since ending your root volume 
iscsi session is fatal, I _would_ like to proactively avoid that 
possibility. So I want to only set this attribute on iscsi root volumes, 
which means it'd have to be a per-node (or per-session) attribute, not a 
global one.


Lastly, I can imagine a time when I want to override safe_logout, say if 
some process is stuck. So it'd be nice to have a "--force" option to end 
a session even if safe_logout is set.


But as I said, these objections are philosophical/theoretical.

And for the record, I like the idea of tracking the "start mode" of 
sessions. Right now, if I list the iscsi sessions, I can't tell which 
ones where started from firmware, which were started in the initrd, and 
which were just manually started. So tracking (and being able to 
display) the startup mode would only be a good thing IMHO.

--
Lee D


--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/181bdb6a-fbaf-1e18-9d08-4bbabf467321%40suse.com.

Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

['Lee Duncan' via open-iscsi]

On 11/30/22 12:08, Mike Christie wrote:

On 11/30/22 1:53 PM, Lee Duncan wrote:

Have you already worked on the open-iscsi side of this? No reason for duplicate 
development.


I think you missed his reply where he said he was missed the
iscsid.safe_logout setting.





No, I saw that, but I thought there were some cases that might be missed 
by checking for mounts. I also think having to set "safe" mode globally 
is inefficient, but that's a separate issue.


Was the plan to retrace the changes submitted and accepted upstream for 
adding a sysfs entry for node_startup that won't be used? Or is the plan 
to populate that attribute for user consumption, even though it isn't 
needed for this particular problem?

--
Lee

--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/9ffb9d42-8ae7-6547-cc5c-1254410a999f%40suse.com.

Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

['Lee Duncan' via open-iscsi]

[A much-reduced CC list, since my reply doesn't need wide distribution.]

On 11/23/22 09:27, Wenchao Hao wrote:

On Thu, Nov 24, 2022 at 12:51 AM Lee Duncan  wrote:


On 11/22/22 20:41, Wenchao Hao wrote:

On 2022/11/23 4:00, Lee Duncan wrote:

On 11/22/22 13:30, Wenchao Hao wrote:

There are 3 iscsi session's startup mode which are onboot, manual and
automatic. We can boot from iSCSI disks with help of dracut's service
in initrd, which would set node's startup mode to onboot, then create
iSCSI sessions.

While the configure of onboot mode is recorded in file of initrd stage
and would be lost when switch to rootfs. Even if we update the startup
mode to onboot by hand after switch to rootfs, it is possible that the
configure would be covered by another discovery command.

root would be mounted on iSCSI disks when boot from iSCSI disks, if the
sessions is logged out, the related disks would be removed, which would
cause the whole system halt.

So we need record session's start up mode in kernel and check this
mode before logout this session.

Signed-off-by: Wenchao Hao 
---
drivers/infiniband/ulp/iser/iscsi_iser.c | 1 +
drivers/scsi/be2iscsi/be_iscsi.c | 1 +
drivers/scsi/bnx2i/bnx2i_iscsi.c | 1 +
drivers/scsi/cxgbi/libcxgbi.c| 1 +
drivers/scsi/iscsi_tcp.c | 1 +
drivers/scsi/libiscsi.c  | 5 +
drivers/scsi/qedi/qedi_iscsi.c   | 1 +
drivers/scsi/qla4xxx/ql4_os.c| 1 +
drivers/scsi/scsi_transport_iscsi.c  | 4 
include/scsi/iscsi_if.h  | 1 +
include/scsi/libiscsi.h  | 1 +
11 files changed, 18 insertions(+)

diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c 
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index 620ae5b2d80d..778c023673ea 100644
--- a/drivers/infiniband/ulp/iser/iscsi_iser.c
+++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
@@ -947,6 +947,7 @@ static umode_t iser_attr_is_visible(int param_type, int 
param)
case ISCSI_PARAM_IFACE_NAME:
case ISCSI_PARAM_INITIATOR_NAME:
case ISCSI_PARAM_DISCOVERY_SESS:
+case ISCSI_PARAM_NODE_STARTUP:
return S_IRUGO;
default:
return 0;
diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index 8aeaddc93b16..a21a4d9ab8b8 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -1401,6 +1401,7 @@ umode_t beiscsi_attr_is_visible(int param_type, int param)
case ISCSI_PARAM_LU_RESET_TMO:
case ISCSI_PARAM_IFACE_NAME:
case ISCSI_PARAM_INITIATOR_NAME:
+case ISCSI_PARAM_NODE_STARTUP:
return S_IRUGO;
default:
return 0;
diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
index a3c800e04a2e..d1fb06d8a92e 100644
--- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
+++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
@@ -2237,6 +2237,7 @@ static umode_t bnx2i_attr_is_visible(int param_type, int 
param)
case ISCSI_PARAM_BOOT_ROOT:
case ISCSI_PARAM_BOOT_NIC:
case ISCSI_PARAM_BOOT_TARGET:
+case ISCSI_PARAM_NODE_STARTUP:
return S_IRUGO;
default:
return 0;
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index af281e271f88..111b2ac78964 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -3063,6 +3063,7 @@ umode_t cxgbi_attr_is_visible(int param_type, int param)
case ISCSI_PARAM_TGT_RESET_TMO:
case ISCSI_PARAM_IFACE_NAME:
case ISCSI_PARAM_INITIATOR_NAME:
+case ISCSI_PARAM_NODE_STARTUP:
return S_IRUGO;
default:
return 0;
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 5fb1f364e815..47a73fb3e4b0 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -1036,6 +1036,7 @@ static umode_t iscsi_sw_tcp_attr_is_visible(int 
param_type, int param)
case ISCSI_PARAM_TGT_RESET_TMO:
case ISCSI_PARAM_IFACE_NAME:
case ISCSI_PARAM_INITIATOR_NAME:
+case ISCSI_PARAM_NODE_STARTUP:
return S_IRUGO;
default:
return 0;
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index d95f4bcdeb2e..1f2b0a9a029e 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -3576,6 +3576,8 @@ int iscsi_set_param(struct iscsi_cls_conn *cls_conn,
break;
case ISCSI_PARAM_LOCAL_IPADDR:
return iscsi_switch_str_param(>local_ipaddr, buf);
+case ISCSI_PARAM_NODE_STARTUP:
+return iscsi_switch_str_param(>node_startup, buf);
default:
return -ENOSYS;
}
@@ -3712,6 +3714,9 @@ int iscsi_session_get_param(struct iscsi_cls_session 
*cls_session,
else
len = sysfs_em

Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

['Lee Duncan' via open-iscsi]

On 11/22/22 20:41, Wenchao Hao wrote:

On 2022/11/23 4:00, Lee Duncan wrote:

On 11/22/22 13:30, Wenchao Hao wrote:

There are 3 iscsi session's startup mode which are onboot, manual and
automatic. We can boot from iSCSI disks with help of dracut's service
in initrd, which would set node's startup mode to onboot, then create
iSCSI sessions.

While the configure of onboot mode is recorded in file of initrd stage
and would be lost when switch to rootfs. Even if we update the startup
mode to onboot by hand after switch to rootfs, it is possible that the
configure would be covered by another discovery command.

root would be mounted on iSCSI disks when boot from iSCSI disks, if the
sessions is logged out, the related disks would be removed, which would
cause the whole system halt.

So we need record session's start up mode in kernel and check this
mode before logout this session.

Signed-off-by: Wenchao Hao 
---
   drivers/infiniband/ulp/iser/iscsi_iser.c | 1 +
   drivers/scsi/be2iscsi/be_iscsi.c | 1 +
   drivers/scsi/bnx2i/bnx2i_iscsi.c | 1 +
   drivers/scsi/cxgbi/libcxgbi.c    | 1 +
   drivers/scsi/iscsi_tcp.c | 1 +
   drivers/scsi/libiscsi.c  | 5 +
   drivers/scsi/qedi/qedi_iscsi.c   | 1 +
   drivers/scsi/qla4xxx/ql4_os.c    | 1 +
   drivers/scsi/scsi_transport_iscsi.c  | 4 
   include/scsi/iscsi_if.h  | 1 +
   include/scsi/libiscsi.h  | 1 +
   11 files changed, 18 insertions(+)

diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c 
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index 620ae5b2d80d..778c023673ea 100644
--- a/drivers/infiniband/ulp/iser/iscsi_iser.c
+++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
@@ -947,6 +947,7 @@ static umode_t iser_attr_is_visible(int param_type, int 
param)
   case ISCSI_PARAM_IFACE_NAME:
   case ISCSI_PARAM_INITIATOR_NAME:
   case ISCSI_PARAM_DISCOVERY_SESS:
+    case ISCSI_PARAM_NODE_STARTUP:
   return S_IRUGO;
   default:
   return 0;
diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index 8aeaddc93b16..a21a4d9ab8b8 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -1401,6 +1401,7 @@ umode_t beiscsi_attr_is_visible(int param_type, int param)
   case ISCSI_PARAM_LU_RESET_TMO:
   case ISCSI_PARAM_IFACE_NAME:
   case ISCSI_PARAM_INITIATOR_NAME:
+    case ISCSI_PARAM_NODE_STARTUP:
   return S_IRUGO;
   default:
   return 0;
diff --git a/drivers/scsi/bnx2i/bnx2i_iscsi.c b/drivers/scsi/bnx2i/bnx2i_iscsi.c
index a3c800e04a2e..d1fb06d8a92e 100644
--- a/drivers/scsi/bnx2i/bnx2i_iscsi.c
+++ b/drivers/scsi/bnx2i/bnx2i_iscsi.c
@@ -2237,6 +2237,7 @@ static umode_t bnx2i_attr_is_visible(int param_type, int 
param)
   case ISCSI_PARAM_BOOT_ROOT:
   case ISCSI_PARAM_BOOT_NIC:
   case ISCSI_PARAM_BOOT_TARGET:
+    case ISCSI_PARAM_NODE_STARTUP:
   return S_IRUGO;
   default:
   return 0;
diff --git a/drivers/scsi/cxgbi/libcxgbi.c b/drivers/scsi/cxgbi/libcxgbi.c
index af281e271f88..111b2ac78964 100644
--- a/drivers/scsi/cxgbi/libcxgbi.c
+++ b/drivers/scsi/cxgbi/libcxgbi.c
@@ -3063,6 +3063,7 @@ umode_t cxgbi_attr_is_visible(int param_type, int param)
   case ISCSI_PARAM_TGT_RESET_TMO:
   case ISCSI_PARAM_IFACE_NAME:
   case ISCSI_PARAM_INITIATOR_NAME:
+    case ISCSI_PARAM_NODE_STARTUP:
   return S_IRUGO;
   default:
   return 0;
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 5fb1f364e815..47a73fb3e4b0 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -1036,6 +1036,7 @@ static umode_t iscsi_sw_tcp_attr_is_visible(int 
param_type, int param)
   case ISCSI_PARAM_TGT_RESET_TMO:
   case ISCSI_PARAM_IFACE_NAME:
   case ISCSI_PARAM_INITIATOR_NAME:
+    case ISCSI_PARAM_NODE_STARTUP:
   return S_IRUGO;
   default:
   return 0;
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index d95f4bcdeb2e..1f2b0a9a029e 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -3576,6 +3576,8 @@ int iscsi_set_param(struct iscsi_cls_conn *cls_conn,
   break;
   case ISCSI_PARAM_LOCAL_IPADDR:
   return iscsi_switch_str_param(>local_ipaddr, buf);
+    case ISCSI_PARAM_NODE_STARTUP:
+    return iscsi_switch_str_param(>node_startup, buf);
   default:
   return -ENOSYS;
   }
@@ -3712,6 +3714,9 @@ int iscsi_session_get_param(struct iscsi_cls_session 
*cls_session,
   else
   len = sysfs_emit(buf, "\n");
   break;
+    case ISCSI_PARAM_NODE_STARTUP:
+    len = sysfs_emit(buf, "%s\n", session->node_startup);
+    break;
   default:
   return -ENOSYS;
 

Re: [PATCH] scsi:iscsi: Record session's startup mode in kernel

['Lee Duncan' via open-iscsi]

   break;
+   case ISCSI_PARAM_NODE_STARTUP:
+   len = sysfs_emit(buf, "%s\n", session->node_startup);
+   break;
default:
return -ENOSYS;
}
diff --git a/drivers/scsi/qedi/qedi_iscsi.c b/drivers/scsi/qedi/qedi_iscsi.c
index 31ec429104e2..b947a5bca380 100644
--- a/drivers/scsi/qedi/qedi_iscsi.c
+++ b/drivers/scsi/qedi/qedi_iscsi.c
@@ -1437,6 +1437,7 @@ static umode_t qedi_attr_is_visible(int param_type, int 
param)
case ISCSI_PARAM_BOOT_ROOT:
case ISCSI_PARAM_BOOT_NIC:
case ISCSI_PARAM_BOOT_TARGET:
+   case ISCSI_PARAM_NODE_STARTUP:
return 0444;
default:
return 0;
diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index 9e849f6b0d0f..1cb7c6dbe9d3 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -468,6 +468,7 @@ static umode_t qla4_attr_is_visible(int param_type, int 
param)
case ISCSI_PARAM_DISCOVERY_PARENT_IDX:
case ISCSI_PARAM_DISCOVERY_PARENT_TYPE:
case ISCSI_PARAM_LOCAL_IPADDR:
+   case ISCSI_PARAM_NODE_STARTUP:
return S_IRUGO;
default:
return 0;
diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index c3fe5ecfee59..39c14d2a8aad 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -4367,6 +4367,7 @@ iscsi_session_attr(tsid, ISCSI_PARAM_TSID, 0);
  iscsi_session_attr(def_taskmgmt_tmo, ISCSI_PARAM_DEF_TASKMGMT_TMO, 0);
  iscsi_session_attr(discovery_parent_idx, ISCSI_PARAM_DISCOVERY_PARENT_IDX, 0);
  iscsi_session_attr(discovery_parent_type, ISCSI_PARAM_DISCOVERY_PARENT_TYPE, 
0);
+iscsi_session_attr(node_startup, ISCSI_PARAM_NODE_STARTUP, 0);
  
  static ssize_t

  show_priv_session_state(struct device *dev, struct device_attribute *attr,
@@ -4488,6 +4489,7 @@ static struct attribute *iscsi_session_attrs[] = {
_attr_sess_def_taskmgmt_tmo.attr,
_attr_sess_discovery_parent_idx.attr,
_attr_sess_discovery_parent_type.attr,
+   _attr_sess_node_startup.attr,
NULL,
  };
  
@@ -4587,6 +4589,8 @@ static umode_t iscsi_session_attr_is_visible(struct kobject *kobj,

return S_IRUGO;
else if (attr == _attr_priv_sess_target_id.attr)
return S_IRUGO;
+   else if (attr == _attr_sess_node_startup.attr)
+   param = ISCSI_PARAM_NODE_STARTUP;
else {
WARN_ONCE(1, "Invalid session attr");
return 0;
diff --git a/include/scsi/iscsi_if.h b/include/scsi/iscsi_if.h
index 5225a23f2d0e..e46e69c1fd02 100644
--- a/include/scsi/iscsi_if.h
+++ b/include/scsi/iscsi_if.h
@@ -610,6 +610,7 @@ enum iscsi_param {
ISCSI_PARAM_DISCOVERY_PARENT_IDX,
ISCSI_PARAM_DISCOVERY_PARENT_TYPE,
ISCSI_PARAM_LOCAL_IPADDR,
+   ISCSI_PARAM_NODE_STARTUP,
/* must always be last */
ISCSI_PARAM_MAX,
  };
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index 654cc3918c94..af4ccdcc1140 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -327,6 +327,7 @@ struct iscsi_session {
char*boot_target;
char*portal_type;
char*discovery_parent_type;
+   char*node_startup;
uint16_tdiscovery_parent_idx;
uint16_tdef_taskmgmt_tmo;
uint16_ttsid;


The iscsiadm/iscsid tools refuse to logout of an ONBOOT session.

--
Lee Duncan

--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/4d21f806-6653-5457-918c-563a3032d128%40suse.com.

Re: [PATCH] scsi:iscsi: rename iscsi_set_param to iscsi_if_set_param

['Lee Duncan' via open-iscsi]

On 11/22/22 10:11, Wenchao Hao wrote:

There are two iscsi_set_param() functions individually defined
in libiscsi.c and scsi_transport_iscsi.c which is confused.

So rename the one in scsi_transport_iscsi.c to iscsi_if_set_param().

Signed-off-by: Wenchao Hao 
---
  drivers/scsi/scsi_transport_iscsi.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index cd3db9684e52..c3fe5ecfee59 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2988,7 +2988,7 @@ iscsi_if_destroy_conn(struct iscsi_transport *transport, 
struct iscsi_uevent *ev
  }
  
  static int

-iscsi_set_param(struct iscsi_transport *transport, struct iscsi_uevent *ev)
+iscsi_if_set_param(struct iscsi_transport *transport, struct iscsi_uevent *ev)
  {
char *data = (char*)ev + sizeof(*ev);
struct iscsi_cls_conn *conn;
@@ -3941,7 +3941,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr 
*nlh, uint32_t *group)
err = -EINVAL;
break;
case ISCSI_UEVENT_SET_PARAM:
-   err = iscsi_set_param(transport, ev);
+   err = iscsi_if_set_param(transport, ev);
break;
case ISCSI_UEVENT_CREATE_CONN:
case ISCSI_UEVENT_DESTROY_CONN:


Reviewed-by: Lee Duncan 

--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/47aa31e2-b49e-739e-dcf8-b91d1becbb73%40suse.com.

Re: [PATCH] drivers: scsi: Directly use ida_alloc()/free()

['Lee Duncan' via open-iscsi]

On 5/27/22 01:30, keliu wrote:

Use ida_alloc()/ida_free() instead of deprecated
ida_simple_get()/ida_simple_remove() .

Signed-off-by: keliu 
---
  drivers/scsi/hosts.c| 4 ++--
  drivers/scsi/scsi_transport_iscsi.c | 6 +++---
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index f69b77cbf538..ec16cfad034e 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -350,7 +350,7 @@ static void scsi_host_dev_release(struct device *dev)
  
  	kfree(shost->shost_data);
  
-	ida_simple_remove(_index_ida, shost->host_no);

+   ida_free(_index_ida, shost->host_no);
  
  	if (shost->shost_state != SHOST_CREATED)

put_device(parent);
@@ -395,7 +395,7 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template 
*sht, int privsize)
init_waitqueue_head(>host_wait);
mutex_init(>scan_mutex);
  
-	index = ida_simple_get(_index_ida, 0, 0, GFP_KERNEL);

+   index = ida_alloc(_index_ida, GFP_KERNEL);
if (index < 0) {
kfree(shost);
return NULL;
diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index 2c0dd64159b0..2578db4c095d 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -1975,7 +1975,7 @@ static void __iscsi_unbind_session(struct work_struct 
*work)
scsi_remove_target(>dev);
  
  	if (session->ida_used)

-   ida_simple_remove(_sess_ida, target_id);
+   ida_free(_sess_ida, target_id);
  
  unbind_session_exit:

iscsi_session_event(session, ISCSI_KEVENT_UNBIND_SESSION);
@@ -2044,7 +2044,7 @@ int iscsi_add_session(struct iscsi_cls_session *session, 
unsigned int target_id)
return -ENOMEM;
  
  	if (target_id == ISCSI_MAX_TARGET) {

-   id = ida_simple_get(_sess_ida, 0, 0, GFP_KERNEL);
+   id = ida_alloc(_sess_ida, GFP_KERNEL);
  
  		if (id < 0) {

iscsi_cls_session_printk(KERN_ERR, session,
@@ -2083,7 +2083,7 @@ int iscsi_add_session(struct iscsi_cls_session *session, 
unsigned int target_id)
device_del(>dev);
  release_ida:
if (session->ida_used)
-   ida_simple_remove(_sess_ida, session->target_id);
+   ida_free(_sess_ida, session->target_id);
  destroy_wq:
destroy_workqueue(session->workq);
return err;


Reviewed-by: Lee Duncan 

--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/e49b3faa-cdac-3e57-4a7f-be2a899ec2af%40suse.com.

Re: [PATCH] scsi: iscsi: fix harmless double shift bug

['Lee Duncan' via open-iscsi]

On 4/21/22 08:03, Dan Carpenter wrote:

These flags are supposed to be bit numbers.  Right now they cause a
double shift bug where we use BIT(BIT(2)) instead of BIT(2).
Fortunately, the bit numbers are small and it's done consistently so it
does not cause an issue at run time.

Fixes: 5bd856256f8c ("scsi: iscsi: Merge suspend fields")
Signed-off-by: Dan Carpenter 
---
  include/scsi/libiscsi.h | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index d0a24779c52d..c0703cd20a99 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -54,9 +54,9 @@ enum {
  #define ISID_SIZE 6
  
  /* Connection flags */

-#define ISCSI_CONN_FLAG_SUSPEND_TX BIT(0)
-#define ISCSI_CONN_FLAG_SUSPEND_RX BIT(1)
-#define ISCSI_CONN_FLAG_BOUND  BIT(2)
+#define ISCSI_CONN_FLAG_SUSPEND_TX 0
+#define ISCSI_CONN_FLAG_SUSPEND_RX 1
+#define ISCSI_CONN_FLAG_BOUND  2
  
  #define ISCSI_ITT_MASK			0x1fff

  #define ISCSI_TOTAL_CMDS_MAX  4096


Reviewed-by: Lee Duncan 

--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/b4e1edb5-ff1d-2215-611b-0bc778f1c7a9%40suse.com.

Re: [PATCH] scsi:libiscsi: remove unnecessary memset in iscsi_conn_setup

['Lee Duncan' via open-iscsi]

On 3/17/22 08:01, Wenchao Hao wrote:

iscsi_cls_conn is alloced by kzalloc(), the whole iscsi_cls_conn is
zero filled already including the dd_data. So it is unnecessary to
call memset again.

Signed-off-by: Wenchao Hao 
Reviewed-by: Wu Bo 
Reviewed-by: Lee Duncan 
---
  drivers/scsi/libiscsi.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index d09926e6c8a8..cf4211c6500d 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -3045,7 +3045,6 @@ iscsi_conn_setup(struct iscsi_cls_session *cls_session, 
int dd_size,
if (!cls_conn)
return NULL;
conn = cls_conn->dd_data;
-   memset(conn, 0, sizeof(*conn) + dd_size);
  
  	conn->dd_data = cls_conn->dd_data + sizeof(*conn);

conn->session = session;


Reviewed-by: Lee Duncan 

--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/bb6aefcf-92aa-ef41-27de-1e3e0b227761%40suse.com.

open-iscsi service iscsi-init can run too early, when FS is read-only

['Lee Duncan' via open-iscsi]

Hi All:

There is an iscsi service that does nothing but create the 
initiatorname.iscsi file in /etc/iscsi if it does not yet exist called 
iscsi-init.service.


For iscsi boot situations, this service can run quite early, in the 
initrd image before the root pivot. Because of this the 
DefaultDependencies=no line was added, so it could run earlier. But 
because of this change, it can now run too early in the real root. The 
problem is that it can actually try to create the initiatorname.iscsi 
file before /etc/iscsi is writable! So it generates an error message, 
fails to create the initiator name, and it makes the rest of iscsi 
services fail, since they depend on iscsi-init.service.


In order to address this, I added this line to the service file:

>
>  [Unit]
>  ...
>  After=root.mount
>

This was an error. I mean to wait for the root disc, not "/root". :( In 
testing, this just happened to work on my systems because we use btrfs 
by default for the root disc, and btrfs creates a "/root" subvolume 
(i.e. mount point).


The mount point target for the root mount is actually called "-.mount". 
But even adding this didn't fix my problem with iscsi-init running too 
early, and it's because iscsi-init was waiting for the root disc to be 
mounted, but it turns out it's mounted read-only for a short time, 
before it's remounted read/write. So it was getting an error trying to 
create the initiator name file.


Long story shorter, I consulted a systemd expert, and he suggested the 
following:



[Unit]
# this adds both Requires= and After=
RequiresMountsFor=/etc/iscsi
# systemd-remount-fs.service is optionally pulled in by
# local-fs.target, don't start it here (no Wants=) but if it's
# running wait for it to finish (After=)
After=systemd-remount-fs.service


and, to keep iscsi-init.service from running before systemd-remote-fs is 
scheduled:



[Install]
# just to ensure being in same transaction with
# systemd-remount-fs.service
WantedBy=systemd-remount-fs.service


Testing has show this works on several different systems, but before I 
"fix" this again, I thought I'd ask for input, in case anyone has 
systemd insight I do not.


Suggestions? If I don't hear anything I'll go with the above 
recommendations.


If I can't figure this out my next suggestion is going to be doing away 
with this service. Once should not ever be in the situation where there 
is no initiator name, since that should be generated when the RPM is 
installed IMHO (which is what we do).

--
Lee Duncan

--
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/d72a3055-5375-de38-d286-8e88fc6c9487%40suse.com.

Re: [PATCH -next] scsi: iscsi: Adjuest iface sysfs attr detection

['Lee Duncan' via open-iscsi]

On 9/1/21 1:53 AM, Baokun Li wrote:
> ISCSI_NET_PARAM_IFACE_ENABLE belongs to enum iscsi_net_param instead of
> iscsi_iface_param，so move it to ISCSI_NET_PARAM. Otherwise, when we call
> into the driver we might not match and return that we don't want attr
> visible in sysfs. Found in code review.
> 
> Fixes: e746f3451ec7 ("scsi: iscsi: Fix iface sysfs attr detection")
> Signed-off-by: Baokun Li 
> ---
>  drivers/scsi/scsi_transport_iscsi.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> index d8b05d8b5470..58027207f08d 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -441,9 +441,7 @@ static umode_t iscsi_iface_attr_is_visible(struct kobject 
> *kobj,
>   struct iscsi_transport *t = iface->transport;
>   int param = -1;
>  
> - if (attr == _attr_iface_enabled.attr)
> - param = ISCSI_NET_PARAM_IFACE_ENABLE;
> - else if (attr == _attr_iface_def_taskmgmt_tmo.attr)
> + if (attr == _attr_iface_def_taskmgmt_tmo.attr)
>   param = ISCSI_IFACE_PARAM_DEF_TASKMGMT_TMO;
>   else if (attr == _attr_iface_header_digest.attr)
>   param = ISCSI_IFACE_PARAM_HDRDGST_EN;
> @@ -483,7 +481,9 @@ static umode_t iscsi_iface_attr_is_visible(struct kobject 
> *kobj,
>   if (param != -1)
>   return t->attr_is_visible(ISCSI_IFACE_PARAM, param);
>  
> - if (attr == _attr_iface_vlan_id.attr)
> + if (attr == _attr_iface_enabled.attr)
> + param = ISCSI_NET_PARAM_IFACE_ENABLE;
> + else if (attr == _attr_iface_vlan_id.attr)
>   param = ISCSI_NET_PARAM_VLAN_ID;
>   else if (attr == _attr_iface_vlan_priority.attr)
>   param = ISCSI_NET_PARAM_VLAN_PRIORITY;
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/91d4e2a7-0a10-ef7b-37b1-3ef884a3c3c0%40suse.com.

Re: Shouldn't firmware nodes be marked as "onboot", for consistency?

[Lee Duncan]

On May 10, 2021, at 4:46 PM, The Lee-Man  wrote:
> 
> 
> Hi All:
> 
> I'm working on getting iBFT (firmware) booting working well using open-iscsi 
> with dual paths and DM/multipathing, and I noticed something.
> 
> When you run "iscsiadm -m discovery -t fw", it creates node database entries 
> for your firmware targets. But it sets "node.startup", and 
> "node.conn[0].startup" to "manual" instead of "onboot", even though 
> open-iscsi treats these entries like "onboot", since they are based on 
> firmware.
> 
> I find it a little more consistent if they are marked as "onboot". A simple 
> path in iscsiadm would change this. Any objections?

Path -> patch 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "open-iscsi" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/open-iscsi/FTmZIFp6_40/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> open-iscsi+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/43e49037-b88c-4954-aa42-54e6807ff259n%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/028D67F8-7303-475C-BFB0-5121E6295C14%40gmail.com.

Re: [PATCH 00/12] open-iscsi: fix serverl issues reported by Coverity

['Lee Duncan' via open-iscsi]

I have reviewed a couple of these, but you need to submit them as pull
requests to github.com/open-iscsi/open-iscsi.

The "reviewed-by" tag I replied to a couple of them really isn't needed,
as I'm the one that will be merging them (or not) on github (sans Chris,
my co-maintainer, who sometimes does that).

On 12/6/20 5:53 PM, Wenchao Hao wrote:
> Recently, we use Coverity to analysis the open-iscsi package.
> Several issues should be resolved to make Coverity happy.
> 
> Wenchao Hao (12):
>   iscsi_sysfs: Fix NULL pointer deference in iscsi_sysfs_read_iface
>   iscsi-iname: Verify open() return value before calling read()
>   iscsiuio: Fix invalid parameter when call fstat()
>   open-iscsi: Fix invalid pointer deference in find_initiator()
>   open-iscsi: Fix NULL pointer dereference in mgmt_ipc_read_req()
>   iscsi_net_util: Fix NULL pointer dereference in find_vlan_dev()
>   open-iscsi: Clean user_param list when process exit
>   fwparam_ppc: Fix NULL pointer dereference in find_devtree()
>   sysfs: Verify parameter of sysfs_device_get()
>   fwparam_ppc: Fix illegal memory access in fwparam_ppc.c
>   iscsiuio: Remove unused macro IFNAMSIZ defined in iscsid_ipc.c
>   fwparam_ppc: Fix memory leak in fwparam_ppc.c
> 
>  iscsiuio/src/unix/iscsid_ipc.c   |  3 --
>  iscsiuio/src/unix/libs/bnx2x.c   |  7 
>  iscsiuio/src/unix/libs/qedi.c|  7 
>  usr/idbm.c   | 14 
>  usr/idbm.h   |  1 +
>  usr/iscsi_net_util.c |  6 
>  usr/iscsi_sysfs.c|  2 +-
>  usr/iscsiadm.c   |  4 +++
>  usr/iscsistart.c |  5 +++
>  usr/mgmt_ipc.c   |  5 ++-
>  usr/sysfs.c  |  6 ++--
>  utils/fwparam_ibft/fwparam_ppc.c | 57 +---
>  utils/iscsi-iname.c  |  6 ++--
>  13 files changed, 102 insertions(+), 21 deletions(-)
> 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/8affd4aa-63af-f05d-2975-86da75f5ebc7%40suse.com.

Re: [PATCH 02/12] iscsi-iname: Verify open() return value before calling read()

['Lee Duncan' via open-iscsi]

On 12/6/20 5:54 PM, Wenchao Hao wrote:
> System call open() might return -1 if an error occurred which
> should be taken into consideration.
> 
> Signed-off-by: Wenchao Hao 
> Signed-off-by: Zhiqiang Liu 
> Signed-off-by: Wu Bo 
> ---
>  utils/iscsi-iname.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/utils/iscsi-iname.c b/utils/iscsi-iname.c
> index 0f587e1..834352e 100644
> --- a/utils/iscsi-iname.c
> +++ b/utils/iscsi-iname.c
> @@ -96,7 +96,8 @@ main(int argc, char *argv[])
>* uniqueness properties
>*/
>  
> - if ((fd = open(RANDOM_NUM_GENERATOR, O_RDONLY))) {
> + fd = open(RANDOM_NUM_GENERATOR, O_RDONLY);
> + if (fd != -1) {
>   e = read(fd, , 16);
>   if (e >= 1)
>   MD5Update(, (md5byte *)entropy, e);
> @@ -141,7 +142,8 @@ main(int argc, char *argv[])
>* good as any other).
>*/
>  
> - if ((fd = open(RANDOM_NUM_GENERATOR, O_RDONLY))) {
> + fd = open(RANDOM_NUM_GENERATOR, O_RDONLY);
> + if (fd != -1) {
>   if (read(fd, entropy, 1) == 1)
>       bytes = [(entropy[0] % (sizeof(digest) - 6))];
>   close(fd);
> 


Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/a7599e2f-ba24-81ba-a76f-3704b94b094f%40suse.com.

Re: [PATCH 01/12] iscsi_sysfs: Fix NULL pointer deference in iscsi_sysfs_read_iface

['Lee Duncan' via open-iscsi]

On 12/6/20 5:53 PM, Wenchao Hao wrote:
> Check if t is valid before accessing it.
> 
> Signed-off-by: Wenchao Hao 
> Signed-off-by: Zhiqiang Liu 
> Signed-off-by: Wu Bo 
> ---
>  usr/iscsi_sysfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/usr/iscsi_sysfs.c b/usr/iscsi_sysfs.c
> index 540adfd..abefde2 100644
> --- a/usr/iscsi_sysfs.c
> +++ b/usr/iscsi_sysfs.c
> @@ -856,7 +856,7 @@ static int iscsi_sysfs_read_iface(struct iface_rec 
> *iface, int host_no,
>   }
>   }
>  
> - if (session && t->template->use_boot_info)
> + if (session && t && t->template->use_boot_info)
>       iscsi_sysfs_read_boot(iface, session);
>  
>   if (!iface_kern_id)
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/10d940f4-7526-275d-4f9f-4d05cfcdd0f1%40suse.com.

[PATCH v2] SCSI: libiscsi: fix NOP race condition

[Lee Duncan]

From: Lee Duncan 

iSCSI NOPs are sometimes "lost", mistakenly sent to the
user-land iscsid daemon instead of handled in the kernel,
as they should be, resulting in a message from the daemon like:

> iscsid: Got nop in, but kernel supports nop handling.

This can occur because of the new forward- and back-locks,
and the fact that an iSCSI NOP response can occur before
processing of the NOP send is complete. This can result
in "conn->ping_task" being NULL in iscsi_nop_out_rsp(),
when the pointer is actually in the process of being set.

To work around this, we add a new state to the "ping_task"
pointer. In addition to NULL (not assigned) and a pointer
(assigned), we add the state "being set", which is signaled
with an INVALID pointer (using "-1").

Changes since V1:
 - expanded using READ_ONCE()/WRITE_ONCE() to the whole path

Signed-off-by: Lee Duncan 
---
 drivers/scsi/libiscsi.c | 23 +++
 include/scsi/libiscsi.h |  3 +++
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 1e9c3171fa9f..f9314f1393fb 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -533,8 +533,8 @@ static void iscsi_complete_task(struct iscsi_task *task, 
int state)
if (conn->task == task)
conn->task = NULL;
 
-   if (conn->ping_task == task)
-   conn->ping_task = NULL;
+   if (READ_ONCE(conn->ping_task) == task)
+   WRITE_ONCE(conn->ping_task, NULL);
 
/* release get from queueing */
__iscsi_put_task(task);
@@ -738,6 +738,9 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct 
iscsi_hdr *hdr,
   task->conn->session->age);
}
 
+   if (unlikely(READ_ONCE(conn->ping_task) == INVALID_SCSI_TASK))
+   WRITE_ONCE(conn->ping_task, task);
+
if (!ihost->workq) {
if (iscsi_prep_mgmt_task(conn, task))
goto free_task;
@@ -941,8 +944,11 @@ static int iscsi_send_nopout(struct iscsi_conn *conn, 
struct iscsi_nopin *rhdr)
 struct iscsi_nopout hdr;
struct iscsi_task *task;
 
-   if (!rhdr && conn->ping_task)
-   return -EINVAL;
+   if (!rhdr) {
+   if (READ_ONCE(conn->ping_task))
+   return -EINVAL;
+   WRITE_ONCE(conn->ping_task, INVALID_SCSI_TASK);
+   }
 
memset(, 0, sizeof(struct iscsi_nopout));
hdr.opcode = ISCSI_OP_NOOP_OUT | ISCSI_OP_IMMEDIATE;
@@ -957,11 +963,12 @@ static int iscsi_send_nopout(struct iscsi_conn *conn, 
struct iscsi_nopin *rhdr)
 
task = __iscsi_conn_send_pdu(conn, (struct iscsi_hdr *), NULL, 0);
if (!task) {
+   if (!rhdr)
+   WRITE_ONCE(conn->ping_task, NULL);
iscsi_conn_printk(KERN_ERR, conn, "Could not send nopout\n");
return -EIO;
} else if (!rhdr) {
/* only track our nops */
-   conn->ping_task = task;
conn->last_ping = jiffies;
}
 
@@ -984,7 +991,7 @@ static int iscsi_nop_out_rsp(struct iscsi_task *task,
struct iscsi_conn *conn = task->conn;
int rc = 0;
 
-   if (conn->ping_task != task) {
+   if (READ_ONCE(conn->ping_task) != task) {
/*
 * If this is not in response to one of our
 * nops then it must be from userspace.
@@ -1923,7 +1930,7 @@ static void iscsi_start_tx(struct iscsi_conn *conn)
  */
 static int iscsi_has_ping_timed_out(struct iscsi_conn *conn)
 {
-   if (conn->ping_task &&
+   if (READ_ONCE(conn->ping_task) &&
time_before_eq(conn->last_recv + (conn->recv_timeout * HZ) +
   (conn->ping_timeout * HZ), jiffies))
return 1;
@@ -2058,7 +2065,7 @@ enum blk_eh_timer_return iscsi_eh_cmd_timed_out(struct 
scsi_cmnd *sc)
 * Checking the transport already or nop from a cmd timeout still
 * running
 */
-   if (conn->ping_task) {
+   if (READ_ONCE(conn->ping_task)) {
task->have_checked_conn = true;
rc = BLK_EH_RESET_TIMER;
goto done;
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index c25fb86ffae9..b3bbd10eb3f0 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -132,6 +132,9 @@ struct iscsi_task {
void*dd_data;   /* driver/transport data */
 };
 
+/* invalid scsi_task pointer */
+#defineINVALID_SCSI_TASK   (struct iscsi_task *)-1l
+
 static inline int iscsi_task_has_unsol_data(struct iscsi_task *task)
 {
return task->unsol_r2t.data_length > task->unsol_r2t.sent;
-- 
2.29.1

-- 
You received this message becaus

Re: [PATCH] scsi: libiscsi: fix NOP race condition

[Lee Duncan]

On 11/4/20 1:33 PM, Mike Christie wrote:
> On 9/18/20 4:09 PM, Lee Duncan wrote:
>> From: Lee Duncan 
>>
>> iSCSI NOPs are sometimes "lost", mistakenly sent to the
>> user-land iscsid daemon instead of handled in the kernel,
>> as they should be, resulting in a message from the daemon like:
>>
>>> iscsid: Got nop in, but kernel supports nop handling.
>>
>> This can occur because of the new forward- and back-locks,
>> and the fact that an iSCSI NOP response can occur before
>> processing of the NOP send is complete. This can result
>> in "conn->ping_task" being NULL in iscsi_nop_out_rsp(),
>> when the pointer is actually in the process of being set.
>>
>> To work around this, we add a new state to the "ping_task"
>> pointer. In addition to NULL (not assigned) and a pointer
>> (assigned), we add the state "being set", which is signaled
>> with an INVALID pointer (using "-1").
>>
>> Signed-off-by: Lee Duncan 
>> ---
>>   drivers/scsi/libiscsi.c | 11 ++-
>>   include/scsi/libiscsi.h |  3 +++
>>   2 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
>> index 1e9c3171fa9f..5eb064787ee2 100644
>> --- a/drivers/scsi/libiscsi.c
>> +++ b/drivers/scsi/libiscsi.c
>> @@ -738,6 +738,9 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn,
>> struct iscsi_hdr *hdr,
>>  task->conn->session->age);
>>   }
>>   +    if (unlikely(READ_ONCE(conn->ping_task) == INVALID_SCSI_TASK))
>> +    WRITE_ONCE(conn->ping_task, task);
>> +
>>   if (!ihost->workq) {
>>   if (iscsi_prep_mgmt_task(conn, task))
>>   goto free_task;
>> @@ -941,6 +944,11 @@ static int iscsi_send_nopout(struct iscsi_conn
>> *conn, struct iscsi_nopin *rhdr)
>>   struct iscsi_nopout hdr;
>>   struct iscsi_task *task;
>>   +    if (!rhdr) {
>> +    if (READ_ONCE(conn->ping_task))
>> +    return -EINVAL;
>> +    WRITE_ONCE(conn->ping_task, INVALID_SCSI_TASK);
>> +    }
>>   if (!rhdr && conn->ping_task)
>>   return -EINVAL;
>>   @@ -957,11 +965,12 @@ static int iscsi_send_nopout(struct iscsi_conn
>> *conn, struct iscsi_nopin *rhdr)
>>     task = __iscsi_conn_send_pdu(conn, (struct iscsi_hdr *),
>> NULL, 0);
>>   if (!task) {
>> +    if (!rhdr)
>> +    WRITE_ONCE(conn->ping_task, NULL);
> 
> I don't think you need this. If __iscsi_conn_send_pdu returns NULL, it
> will have done __iscsi_put_task and done this already.

Not an issue, as you already replied.

> 
>>   iscsi_conn_printk(KERN_ERR, conn, "Could not send nopout\n");
>>   return -EIO;
>>   } else if (!rhdr) {
>>   /* only track our nops */
>> -    conn->ping_task = task;
>>   conn->last_ping = jiffies;
>>   }
> 
> Why in the send path do we always use the READ_ONCE/WRITE_ONCE, but in
> the completion path like in iscsi_complete_task we don't.
> 

The answer is that I was only modifying the code that needed changing
for this bug. My first pass did not use READ_ONCE() or WRITE_ONCE(), but
Hannes suggested the change.

Now that I think about it more, the memory barrier stuff would make
sense only if all the access to that field are protected.

I will resubmit V2 of the patch.
-- 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/c43612c1-14d7-4ccb-007f-23b9df1474cc%40suse.com.

Re: [PATCH] open-iscsi: Fix memory leak in sysfs_get_str

[Lee Duncan]

On 11/4/20 6:59 PM, Wenchao Hao wrote:
> strlen(sysfs_value) return 0 do not mean sysfs_value
> is NULL and this memory should be freed
> 
> Signed-off-by: Wenchao Hao 
> ---
>  usr/sysfs.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/usr/sysfs.c b/usr/sysfs.c
> index 2488160..8d37c69 100644
> --- a/usr/sysfs.c
> +++ b/usr/sysfs.c
> @@ -574,8 +574,12 @@ int sysfs_get_str(char *id, char *subsys, char *param, 
> char *value,
>  
>   value[0] = '\0';
>   sysfs_value = sysfs_get_value(id, subsys, param);
> - if (!sysfs_value || !strlen(sysfs_value))
> + if (!sysfs_value)
> + return EIO;
> + if (!strlen(sysfs_value)) {
> + free(sysfs_value);
>   return EIO;
> + }
>  
>   len = strlen(sysfs_value);
>   if (len && (sysfs_value[len - 1] == '\n'))
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/802c3a31-3c66-0947-31b1-df610196c5ac%40suse.com.

Re: [PATCH] scsi: libiscsi: Fix cmds hung when sd_shutdown

[Lee Duncan]

On 10/31/20 1:23 AM, Wu Bo wrote:
> For some reason, during reboot the system, iscsi.service failed to
> logout all sessions. kernel will hang forever on its
> sd_sync_cache() logic, after issuing the SYNCHRONIZE_CACHE cmd to all
> still existent paths.
> 
> [ 1044.098991] reboot: Mddev shutdown finished.
> [ 1044.099311] reboot: Usermodehelper disable finished.
> [ 1050.611244]  connection2:0: ping timeout of 5 secs expired, recv timeout 
> 5, last rx 4295152378, last ping 4295153633, now 4295154944
> [ 1348.599676] Call trace:
> [ 1348.599887]  __switch_to+0xe8/0x150
> [ 1348.600113]  __schedule+0x33c/0xa08
> [ 1348.600372]  schedule+0x2c/0x88
> [ 1348.600567]  schedule_timeout+0x184/0x3a8
> [ 1348.600820]  io_schedule_timeout+0x28/0x48
> [ 1348.601089]  wait_for_common_io.constprop.2+0x168/0x258
> [ 1348.601425]  wait_for_completion_io_timeout+0x28/0x38
> [ 1348.601762]  blk_execute_rq+0x98/0xd8
> [ 1348.602006]  __scsi_execute+0xe0/0x1e8
> [ 1348.602262]  sd_sync_cache+0xd0/0x220 [sd_mod]
> [ 1348.602551]  sd_shutdown+0x6c/0xf8 [sd_mod]
> [ 1348.602826]  device_shutdown+0x13c/0x250
> [ 1348.603078]  kernel_restart_prepare+0x5c/0x68
> [ 1348.603400]  kernel_restart+0x20/0x98
> [ 1348.603683]  __se_sys_reboot+0x214/0x260
> [ 1348.603987]  __arm64_sys_reboot+0x24/0x30
> [ 1348.604300]  el0_svc_common+0x80/0x1b8
> [ 1348.604590]  el0_svc_handler+0x78/0xe0
> [ 1348.604877]  el0_svc+0x10/0x260
> 
> d754941225 (scsi: libiscsi: Allow sd_shutdown on bad transport) Once
> solved this problem. The iscsi_eh_cmd_timed_out() function add system_state
> judgment, and will return BLK_EH_DONE and mark the result as 
> DID_NO_CONNECT when system_state is not SYSTEM_RUNNING, 
> To tell upper layers that the command was handled during 
> the transport layer error handler helper.
> 
> The scsi Mid Layer timeout handler function(scsi_times_out) will be
> abort the cmd if the scsi LLD timeout handler return BLK_EH_DONE.
> if abort cmd failed, will enter scsi EH logic.
> 
> Scsi EH will do reset target logic, if reset target failed, Will
> call iscsi_eh_session_reset() function to drop the session.
> 
> The iscsi_eh_session_reset function will wait for a relogin,
> session termination from userspace, or a recovery/replacement timeout.
> But at this time, the app iscsid has exited, and the session was marked as
> ISCSI_STATE_FAILED, So the SCSI EH process will never be 
> scheduled back again.
> 
> PID: 9123   TASK: 80020c1b4d80  CPU: 3   COMMAND: "scsi_eh_2"
>  #0 [8632bb70] __switch_to at 80088738
>  #1 [8632bb90] __schedule at 80a00480
>  #2 [8632bc20] schedule at 80a00b58
>  #3 [8632bc30] iscsi_eh_session_reset at 00d1ab9c [libiscsi]
>  #4 [8632bcb0] iscsi_eh_recover_target at 00d1d1fc [libiscsi]
>  #5 [8632bd00] scsi_try_target_reset at 806f0bac
>  #6 [8632bd30] scsi_eh_ready_devs at 806f2724
>  #7 [8632bde0] scsi_error_handler at 806f41d4
>  #8 [8632be70] kthread at 80119ae0
> 
> Reported-by: Tianxiong Lu 
> Signed-off-by: Wu Bo 
> ---
>  drivers/scsi/libiscsi.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index 1e9c317..2570768 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -2380,7 +2380,17 @@ int iscsi_eh_session_reset(struct scsi_cmnd *sc)
>  
>   mutex_lock(>eh_mutex);
>   spin_lock_bh(>frwd_lock);
> - if (session->state == ISCSI_STATE_TERMINATE) {
> +
> + /*
> +  * During shutdown, if session is prematurely disconnected
> +  * recovery won't happen and there will be hung cmds.
> +  * To solve this case, all cmds would be enter scsi EH.
> +  * But the EH path will wait for wait_event_interruptible() completed,
> +  * when the session state machine is not ISCSI_STATE_TERMINATE,
> +  * ISCSI_STATE_LOGGED_IN and ISCSI_STATE_RECOVERY_FAILED.
> +  */
> + if (session->state == ISCSI_STATE_TERMINATE ||
> + unlikely(system_state != SYSTEM_RUNNING)) {
>  failed:
>   ISCSI_DBG_EH(session,
>"failing session reset: Could not log back into "
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/10d05ca7-717a-1592-3ecb-78e56ad99763%40suse.com.

Re: Slow iSCSI tape performance

[Lee Duncan]

On Oct 25, 2020, at 10:42 AM, David C. Partridge 
 wrote:
> 
> I believe that it’s something to do with stopping Windows (at the target) 
> from sending TURs to the tape every 30s or so.

Okay, that makes sense. But that has nothing to do with open-iscsi, or even 
iSCSI at all.

>  
> Setting streaming bit ? Is that something I can do with mt-st or mt commands? 
>  The best I am getting is about 29MB/s over a 1Gbit LAN L

I was talking about the ability to tell st to write tape marks without waiting. 
This is very handy for streaming tape drives, since it allows it to stream tape 
marks as well. But it cannot be set with “mt” — it needs an ioctl().

What kind of throughput does the tape drive supply directly?

>  
> Here’s my backup script:
> ...

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/CCD69511-2C68-4703-9BDD-A1345922DA2D%40gmail.com.

Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

[Lee Duncan]

On 10/8/20 1:54 PM, Mike Christie wrote:
> On 10/8/20 12:11 PM, Mike Christie wrote:
>> On 9/25/20 1:41 PM, ldun...@suse.com wrote:
>>> From: Lee Duncan 
>>>
>>> iSCSI NOPs are sometimes "lost", mistakenly sent to the
>>> user-land iscsid daemon instead of handled in the kernel,
>>> as they should be, resulting in a message from the daemon like:
>>>
>>>> iscsid: Got nop in, but kernel supports nop handling.
>>>
>>> This can occur because of the forward- and back-locks
>>> in the kernel iSCSI code, and the fact that an iSCSI NOP
>>> response can be processed before processing of the NOP send
>>> is complete. This can result in "conn->ping_task" being NULL
>>> in iscsi_nop_out_rsp(), when the pointer is actually in
>>> the process of being set.
>>>
>>> To work around this, we add a new state to the "ping_task"
>>> pointer. In addition to NULL (not assigned) and a pointer
>>> (assigned), we add the state "being set", which is signaled
>>> with an INVALID pointer (using "-1").
>>>
>>> Signed-off-by: Lee Duncan 
>>> ---
>>>  drivers/scsi/libiscsi.c | 13 ++---
>>>  include/scsi/libiscsi.h |  3 +++
>>>  2 files changed, 13 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
>>> index 1e9c3171fa9f..cade108c33b6 100644
>>> --- a/drivers/scsi/libiscsi.c
>>> +++ b/drivers/scsi/libiscsi.c
>>> @@ -738,6 +738,9 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct 
>>> iscsi_hdr *hdr,
>>>task->conn->session->age);
>>> }
>>>  
>>> +   if (unlikely(READ_ONCE(conn->ping_task) == INVALID_SCSI_TASK))
>>> +   WRITE_ONCE(conn->ping_task, task);
>>> +
>>> if (!ihost->workq) {
>>> if (iscsi_prep_mgmt_task(conn, task))
>>> goto free_task;
>>
>> I think the API gets a little weird now where in some cases
>> __iscsi_conn_send_pdu checks the opcode to see what type of request
>> it is but above we the caller sets the ping_task.
>>
>> For login, tmfs and passthrough, we assume the __iscsi_conn_send_pdu
>> has sent or cleaned up everything. I think it might be nicer to just
>> have __iscsi_conn_send_pdu set the ping_task field before doing the
>> xmit/queue call. It would then work similar to the conn->login_task
>> case where that function knows about that special task too.
>>
>> So in __iscsi_conn_send_pdu add a "if (opcode == ISCSI_OP_NOOP_OUT)",
>> and check if it's a nop we need to track. If so set conn->ping_task.
>>
> Ignore this. It won't work nicely either. To figure out if the nop is
> our internal transport test ping vs a userspace ping that also needs
> a reply, we would need to do something like you did above so there is
> no point.
> 

Hi Mike:

I've read this a few times, and I'm still no sure I'm parsing it correctly.

Are you saying that my original patch submission is ok, or are you
saying there's nothing we can do and we're up the proverbial creek?
-- 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/480f8554-b13a-45b2-98b4-dec4762d093f%40suse.com.

Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

[Lee Duncan]

On 9/25/20 11:41 AM, ldun...@suse.com wrote:
> From: Lee Duncan 
> 
> iSCSI NOPs are sometimes "lost", mistakenly sent to the
> user-land iscsid daemon instead of handled in the kernel,
> as they should be, resulting in a message from the daemon like:
> 
>> iscsid: Got nop in, but kernel supports nop handling.
> 
> This can occur because of the forward- and back-locks
> in the kernel iSCSI code, and the fact that an iSCSI NOP
> response can be processed before processing of the NOP send
> is complete. This can result in "conn->ping_task" being NULL
> in iscsi_nop_out_rsp(), when the pointer is actually in
> the process of being set.
> 
> To work around this, we add a new state to the "ping_task"
> pointer. In addition to NULL (not assigned) and a pointer
> (assigned), we add the state "being set", which is signaled
> with an INVALID pointer (using "-1").
> 
> Signed-off-by: Lee Duncan 
> ---
>  drivers/scsi/libiscsi.c | 13 ++---
>  include/scsi/libiscsi.h |  3 +++
>  2 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index 1e9c3171fa9f..cade108c33b6 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -738,6 +738,9 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct 
> iscsi_hdr *hdr,
>  task->conn->session->age);
>   }
>  
> + if (unlikely(READ_ONCE(conn->ping_task) == INVALID_SCSI_TASK))
> + WRITE_ONCE(conn->ping_task, task);
> +
>   if (!ihost->workq) {
>   if (iscsi_prep_mgmt_task(conn, task))
>   goto free_task;
> @@ -941,8 +944,11 @@ static int iscsi_send_nopout(struct iscsi_conn *conn, 
> struct iscsi_nopin *rhdr)
>  struct iscsi_nopout hdr;
>   struct iscsi_task *task;
>  
> - if (!rhdr && conn->ping_task)
> - return -EINVAL;
> + if (!rhdr) {
> + if (READ_ONCE(conn->ping_task))
> + return -EINVAL;
> + WRITE_ONCE(conn->ping_task, INVALID_SCSI_TASK);
> + }
>  
>   memset(, 0, sizeof(struct iscsi_nopout));
>   hdr.opcode = ISCSI_OP_NOOP_OUT | ISCSI_OP_IMMEDIATE;
> @@ -957,11 +963,12 @@ static int iscsi_send_nopout(struct iscsi_conn *conn, 
> struct iscsi_nopin *rhdr)
>  
>   task = __iscsi_conn_send_pdu(conn, (struct iscsi_hdr *), NULL, 0);
>   if (!task) {
> + if (!rhdr)
> + WRITE_ONCE(conn->ping_task, NULL);
>   iscsi_conn_printk(KERN_ERR, conn, "Could not send nopout\n");
>   return -EIO;
>   } else if (!rhdr) {
>   /* only track our nops */
> - conn->ping_task = task;
>   conn->last_ping = jiffies;
>   }
>  
> diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
> index c25fb86ffae9..b3bbd10eb3f0 100644
> --- a/include/scsi/libiscsi.h
> +++ b/include/scsi/libiscsi.h
> @@ -132,6 +132,9 @@ struct iscsi_task {
>   void    *dd_data;   /* driver/transport data */
>  };
>  
> +/* invalid scsi_task pointer */
> +#define  INVALID_SCSI_TASK   (struct iscsi_task *)-1l
> +
>  static inline int iscsi_task_has_unsol_data(struct iscsi_task *task)
>  {
>   return task->unsol_r2t.data_length > task->unsol_r2t.sent;
> 

Ping?

-- 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/a13eb063-f374-9a9a-0dac-a8fcb702c9b8%40suse.com.

Re: [PATCH v9 6/7] scsi: libiscsi: use sendpage_ok() in iscsi_tcp_segment_map()

[Lee Duncan]

On 10/1/20 12:54 AM, Coly Li wrote:
> In iscsci driver, iscsi_tcp_segment_map() uses the following code to
> check whether the page should or not be handled by sendpage:
> if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)))
> 
> The "page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)" part is to
> make sure the page can be sent to network layer's zero copy path. This
> part is exactly what sendpage_ok() does.
> 
> This patch uses  use sendpage_ok() in iscsi_tcp_segment_map() to replace
> the original open coded checks.
> 
> Signed-off-by: Coly Li 
> Acked-by: Martin K. Petersen 
> Cc: Vasily Averin 
> Cc: Cong Wang 
> Cc: Mike Christie 
> Cc: Lee Duncan 
> Cc: Chris Leech 
> Cc: Christoph Hellwig 
> Cc: Hannes Reinecke 
> ---
>  drivers/scsi/libiscsi_tcp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c
> index 37e5d4e48c2f..83f14b2c8804 100644
> --- a/drivers/scsi/libiscsi_tcp.c
> +++ b/drivers/scsi/libiscsi_tcp.c
> @@ -128,7 +128,7 @@ static void iscsi_tcp_segment_map(struct iscsi_segment 
> *segment, int recv)
>* coalescing neighboring slab objects into a single frag which
>* triggers one of hardened usercopy checks.
>*/
> - if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)))
> + if (!recv && sendpage_ok(sg_page(sg)))
>   return;
>  
>   if (recv) {
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/0df9cb0e-7fd1-5ba0-564a-378aa0b8955f%40suse.com.

[PATCH] scsi: libiscsi: fix NOP race condition

[Lee Duncan]

From: Lee Duncan 

iSCSI NOPs are sometimes "lost", mistakenly sent to the
user-land iscsid daemon instead of handled in the kernel,
as they should be, resulting in a message from the daemon like:

> iscsid: Got nop in, but kernel supports nop handling.

This can occur because of the new forward- and back-locks,
and the fact that an iSCSI NOP response can occur before
processing of the NOP send is complete. This can result
in "conn->ping_task" being NULL in iscsi_nop_out_rsp(),
when the pointer is actually in the process of being set.

To work around this, we add a new state to the "ping_task"
pointer. In addition to NULL (not assigned) and a pointer
(assigned), we add the state "being set", which is signaled
with an INVALID pointer (using "-1").

Signed-off-by: Lee Duncan 
---
 drivers/scsi/libiscsi.c | 11 ++-
 include/scsi/libiscsi.h |  3 +++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 1e9c3171fa9f..5eb064787ee2 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -738,6 +738,9 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct 
iscsi_hdr *hdr,
   task->conn->session->age);
}
 
+   if (unlikely(READ_ONCE(conn->ping_task) == INVALID_SCSI_TASK))
+   WRITE_ONCE(conn->ping_task, task);
+
if (!ihost->workq) {
if (iscsi_prep_mgmt_task(conn, task))
goto free_task;
@@ -941,6 +944,11 @@ static int iscsi_send_nopout(struct iscsi_conn *conn, 
struct iscsi_nopin *rhdr)
 struct iscsi_nopout hdr;
struct iscsi_task *task;
 
+   if (!rhdr) {
+   if (READ_ONCE(conn->ping_task))
+   return -EINVAL;
+   WRITE_ONCE(conn->ping_task, INVALID_SCSI_TASK);
+   }
if (!rhdr && conn->ping_task)
return -EINVAL;
 
@@ -957,11 +965,12 @@ static int iscsi_send_nopout(struct iscsi_conn *conn, 
struct iscsi_nopin *rhdr)
 
task = __iscsi_conn_send_pdu(conn, (struct iscsi_hdr *), NULL, 0);
if (!task) {
+   if (!rhdr)
+   WRITE_ONCE(conn->ping_task, NULL);
iscsi_conn_printk(KERN_ERR, conn, "Could not send nopout\n");
return -EIO;
} else if (!rhdr) {
/* only track our nops */
-   conn->ping_task = task;
conn->last_ping = jiffies;
}
 
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index c25fb86ffae9..b3bbd10eb3f0 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -132,6 +132,9 @@ struct iscsi_task {
void*dd_data;   /* driver/transport data */
 };
 
+/* invalid scsi_task pointer */
+#defineINVALID_SCSI_TASK   (struct iscsi_task *)-1l
+
 static inline int iscsi_task_has_unsol_data(struct iscsi_task *task)
 {
return task->unsol_r2t.data_length > task->unsol_r2t.sent;
-- 
2.26.2

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/20200918210947.23800-1-leeman.duncan%40gmail.com.

Re: [PATCH] scsi: iscsi: register sysfs for workqueue iscsi_destroy

[Lee Duncan]

On 7/3/20 8:59 PM, Mike Christie wrote:
> On 7/3/20 12:16 AM, Bob Liu wrote:
>> Register sysfs for workqueue iscsi_destroy, so that users can set cpu
>> affinity
>> through "cpumask" for this workqueue to get better isolation in cloud
>> multi-tenant scenario.
>>
>> This patch unfolded create_singlethread_workqueue(), added WQ_SYSFS
>> and drop
>> __WQ_ORDERED_EXPLICIT since __WQ_ORDERED_EXPLICIT workqueue isn't
>> allowed to
>> change "cpumask".
>>
>> Suggested-by: Mike Christie 
>> Signed-off-by: Bob Liu 
>> ---
>>   drivers/scsi/scsi_transport_iscsi.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/scsi/scsi_transport_iscsi.c
>> b/drivers/scsi/scsi_transport_iscsi.c
>> index 7ae5024..aa8d4a3 100644
>> --- a/drivers/scsi/scsi_transport_iscsi.c
>> +++ b/drivers/scsi/scsi_transport_iscsi.c
>> @@ -4766,7 +4766,9 @@ static __init int iscsi_transport_init(void)
>>   goto release_nls;
>>   }
>>   -    iscsi_destroy_workq =
>> create_singlethread_workqueue("iscsi_destroy");
>> +    iscsi_destroy_workq = alloc_workqueue("%s",
>> +    WQ_SYSFS | __WQ_LEGACY | WQ_MEM_RECLAIM | WQ_UNBOUND,
>> +    1, "iscsi_destroy");
>>   if (!iscsi_destroy_workq) {
>>   err = -ENOMEM;
>>   goto destroy_wq;
>>
> 
> Reviewed-by: Mike Christie 
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/cebb8331-de5c-c16e-2837-756355954a7c%40suse.com.

Re: [PATCH] scsi: iscsi: register sysfs for workqueue iscsi_destroy

[Lee Duncan]

On 7/2/20 10:16 PM, Bob Liu wrote:
> Register sysfs for workqueue iscsi_destroy, so that users can set cpu affinity
> through "cpumask" for this workqueue to get better isolation in cloud
> multi-tenant scenario.
> 
> This patch unfolded create_singlethread_workqueue(), added WQ_SYSFS and drop
> __WQ_ORDERED_EXPLICIT since __WQ_ORDERED_EXPLICIT workqueue isn't allowed to
> change "cpumask".
> 
> Suggested-by: Mike Christie 
> Signed-off-by: Bob Liu 
> ---
>  drivers/scsi/scsi_transport_iscsi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> index 7ae5024..aa8d4a3 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -4766,7 +4766,9 @@ static __init int iscsi_transport_init(void)
>   goto release_nls;
>   }
>  
> - iscsi_destroy_workq = create_singlethread_workqueue("iscsi_destroy");
> + iscsi_destroy_workq = alloc_workqueue("%s",
> + WQ_SYSFS | __WQ_LEGACY | WQ_MEM_RECLAIM | WQ_UNBOUND,
> + 1, "iscsi_destroy");
>   if (!iscsi_destroy_workq) {
>   err = -ENOMEM;
>   goto destroy_wq;
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/691c7f84-fb9b-c897-14ad-5c5b6b087b52%40suse.com.

Re: [PATCH] scsi: Fix reference count leak in iscsi_boot_create_kobj.

[Lee Duncan]

On 5/28/20 1:13 PM, wu000...@umn.edu wrote:
> From: Qiushi Wu 
> 
> kobject_init_and_add() should be handled when it return an error,
> because kobject_init_and_add() takes reference even when it fails.
> If this function returns an error, kobject_put() must be called to
> properly clean up the memory associated with the object. Previous
> commit "b8eb718348b8" fixed a similar problem. Thus replace calling
> kfree() by calling kobject_put().
> 
> Signed-off-by: Qiushi Wu 
> ---
>  drivers/scsi/iscsi_boot_sysfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/iscsi_boot_sysfs.c b/drivers/scsi/iscsi_boot_sysfs.c
> index e4857b728033..a64abe38db2d 100644
> --- a/drivers/scsi/iscsi_boot_sysfs.c
> +++ b/drivers/scsi/iscsi_boot_sysfs.c
> @@ -352,7 +352,7 @@ iscsi_boot_create_kobj(struct iscsi_boot_kset *boot_kset,
>   boot_kobj->kobj.kset = boot_kset->kset;
>   if (kobject_init_and_add(_kobj->kobj, _boot_ktype,
>NULL, name, index)) {
> - kfree(boot_kobj);
> + kobject_put(_kobj->kobj);
>   return NULL;
>   }
>   boot_kobj->data = data;
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/2d158fc5-a0b5-718d-d70a-3dfe9db22482%40suse.com.

Re: [RFC RESEND PATCH v2] scsi: iscsi: register sysfs for iscsi workqueue

[Lee Duncan]

On 5/25/20 2:16 AM, Bob Liu wrote:
> friendly ping.
> 
> On 5/5/20 9:19 AM, Bob Liu wrote:
>> Motivation:
>> This patch enable setting cpu affinity through "cpumask" for iscsi workqueues
>> (iscsi_q_xx and iscsi_eh), so as to get performance isolation.
>>
>> The max number of active worker was changed form 1 to 2, because "cpumask" of
>> ordered workqueue isn't allowed to change.
>>
>> Notes:
>> - Having 2 workers break the current ordering guarantees, please let me know
>>   if anyone depends on this.
>>
>> - __WQ_LEGACY have to be left because of
>> 23d11a5(workqueue: skip flush dependency checks for legacy workqueues)
>>
>> Signed-off-by: Bob Liu 
>> ---
>>  drivers/scsi/libiscsi.c | 4 +++-
>>  drivers/scsi/scsi_transport_iscsi.c | 4 +++-
>>  2 files changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
>> index 70b99c0..adf9bb4 100644
>> --- a/drivers/scsi/libiscsi.c
>> +++ b/drivers/scsi/libiscsi.c
>> @@ -2627,7 +2627,9 @@ struct Scsi_Host *iscsi_host_alloc(struct 
>> scsi_host_template *sht,
>>  if (xmit_can_sleep) {
>>  snprintf(ihost->workq_name, sizeof(ihost->workq_name),
>>  "iscsi_q_%d", shost->host_no);
>> -ihost->workq = create_singlethread_workqueue(ihost->workq_name);
>> +ihost->workq = alloc_workqueue("%s",
>> +WQ_SYSFS | __WQ_LEGACY | WQ_MEM_RECLAIM | WQ_UNBOUND,
>> +2, ihost->workq_name);
>>  if (!ihost->workq)
>>  goto free_host;
>>  }
>> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
>> b/drivers/scsi/scsi_transport_iscsi.c
>> index dfc726f..bdbc4a2 100644
>> --- a/drivers/scsi/scsi_transport_iscsi.c
>> +++ b/drivers/scsi/scsi_transport_iscsi.c
>> @@ -4602,7 +4602,9 @@ static __init int iscsi_transport_init(void)
>>  goto unregister_flashnode_bus;
>>  }
>>  
>> -iscsi_eh_timer_workq = create_singlethread_workqueue("iscsi_eh");
>> +iscsi_eh_timer_workq = alloc_workqueue("%s",
>> +WQ_SYSFS | __WQ_LEGACY | WQ_MEM_RECLAIM | WQ_UNBOUND,
>> +2, "iscsi_eh");
>>  if (!iscsi_eh_timer_workq) {
>>  err = -ENOMEM;
>>  goto release_nls;
>>
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/102630b7-f126-a478-ba73-06f863438982%40suse.com.

Re: [PATCH] iscsi: Fix deadlock on recovery path during GFP_IO reclaim

[Lee Duncan]

On 5/18/20 11:53 AM, Gabriel Krisman Bertazi wrote:
> Lee Duncan  writes:
> 
>> On 5/7/20 10:59 PM, Gabriel Krisman Bertazi wrote:
>>> iscsi suffers from a deadlock in case a management command submitted via
>>> the netlink socket sleeps on an allocation while holding the
>>> rx_queue_mutex, if that allocation causes a memory reclaim that
>>> writebacks to a failed iscsi device.  Then, the recovery procedure can
>>> never make progress to recover the failed disk or abort outstanding IO
>>> operations to complete the reclaim (since rx_queue_mutex is locked),
>>> thus locking the system.
>>>
>>> Nevertheless, just marking all allocations under rx_queue_mutex as
>>> GFP_NOIO (or locking the userspace process with something like
>>> PF_MEMALLOC_NOIO) is not enough, since the iscsi command code relies on
>>> other subsystems that try to grab locked mutexes, whose threads are
>>> GFP_IO, leading to the same deadlock. One instance where this situation
>>> can be observed is in the backtraces below, stitched from multiple bugs
>>> reports, involving the kobj uevent sent when a session is created.
>>>
>>> The root of the problem is not the fact that iscsi does GFP_IO
>>> allocations, that is acceptable. The actual problem is that
>>> rx_queue_mutex has a very large granularity, covering every unrelated
>>> netlink command execution at the same time as the error recovery path.
>>>
>>> The proposed fix leverages the recently added mechanism to stop failed
>>> connections from the kernel, by enabling it to execute even though a
>>> management command from the netlink socket is being run (rx_queue_mutex
>>> is held), provided that the command is known to be safe.  It splits the
>>> rx_queue_mutex in two mutexes, one protecting from concurrent command
>>> execution from the netlink socket, and one protecting stop_conn from
>>> racing with other connection management operations that might conflict
>>> with it.
>>>
>>> It is not very pretty, but it is the simplest way to resolve the
>>> deadlock.  I considered making it a lock per connection, but some
>>> external mutex would still be needed to deal with iscsi_if_destroy_conn.
>>>
>>> The patch was tested by forcing a memory shrinker (unrelated, but used
>>> bufio/dm-verity) to reclaim ISCSI pages every time
>>> ISCSI_UEVENT_CREATE_SESSION happens, which is reasonable to simulate
>>> reclaims that might happen with GFP_KERNEL on that path.  Then, a faulty
>>> hung target causes a connection to fail during intensive IO, at the same
>>> time a new session is added by iscsid.
>>>
>>> The following stacktraces are stiches from several bug reports, showing
>>> a case where the deadlock can happen.
>>>
>>>  iSCSI-write
>>>  holding: rx_queue_mutex
>>>  waiting: uevent_sock_mutex
>>>
>>>  kobject_uevent_env+0x1bd/0x419
>>>  kobject_uevent+0xb/0xd
>>>  device_add+0x48a/0x678
>>>  scsi_add_host_with_dma+0xc5/0x22d
>>>  iscsi_host_add+0x53/0x55
>>>  iscsi_sw_tcp_session_create+0xa6/0x129
>>>  iscsi_if_rx+0x100/0x1247
>>>  netlink_unicast+0x213/0x4f0
>>>  netlink_sendmsg+0x230/0x3c0
>>>
>>>  iscsi_fail iscsi_conn_failure
>>>  waiting: rx_queue_mutex
>>>
>>>  schedule_preempt_disabled+0x325/0x734
>>>  __mutex_lock_slowpath+0x18b/0x230
>>>  mutex_lock+0x22/0x40
>>>  iscsi_conn_failure+0x42/0x149
>>>  worker_thread+0x24a/0xbc0
>>>
>>>  EventManager_
>>>  holding: uevent_sock_mutex
>>>  waiting: dm_bufio_client->lock
>>>
>>>  dm_bufio_lock+0xe/0x10
>>>  shrink+0x34/0xf7
>>>  shrink_slab+0x177/0x5d0
>>>  do_try_to_free_pages+0x129/0x470
>>>  try_to_free_mem_cgroup_pages+0x14f/0x210
>>>  memcg_kmem_newpage_charge+0xa6d/0x13b0
>>>  __alloc_pages_nodemask+0x4a3/0x1a70
>>>  fallback_alloc+0x1b2/0x36c
>>>  __kmalloc_node_track_caller+0xb9/0x10d0
>>>  __alloc_skb+0x83/0x2f0
>>>  kobject_uevent_env+0x26b/0x419
>>>  dm_kobject_uevent+0x70/0x79
>>>  dev_suspend+0x1a9/0x1e7
>>>  ctl_ioctl+0x3e9/0x411
>>>  dm_ctl_ioctl+0x13/0x17
>>>  do

Re: [PATCH] iscsi: Fix deadlock on recovery path during GFP_IO reclaim

[Lee Duncan]

  }
>  
> + mutex_lock(_mutex);
>   ev->r.retcode = transport->bind_conn(session, conn,
>   ev->u.b_conn.transport_eph,
>   ev->u.b_conn.is_leading);
> + mutex_unlock(_mutex);
> +
>   if (ev->r.retcode || !transport->ep_connect)
>   break;
>  
> @@ -3709,25 +3734,31 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct 
> nlmsghdr *nlh, uint32_t *group)
>   break;
>   case ISCSI_UEVENT_START_CONN:
>   conn = iscsi_conn_lookup(ev->u.start_conn.sid, 
> ev->u.start_conn.cid);
> - if (conn)
> + if (conn) {
> + mutex_lock(_mutex);
>   ev->r.retcode = transport->start_conn(conn);
> + mutex_unlock(_mutex);
> + }
>   else
>   err = -EINVAL;
>   break;
>   case ISCSI_UEVENT_STOP_CONN:
>   conn = iscsi_conn_lookup(ev->u.stop_conn.sid, 
> ev->u.stop_conn.cid);
>   if (conn)
> - transport->stop_conn(conn, ev->u.stop_conn.flag);
> + iscsi_if_stop_conn(conn, ev->u.stop_conn.flag);
>   else
>   err = -EINVAL;
>   break;
>   case ISCSI_UEVENT_SEND_PDU:
>   conn = iscsi_conn_lookup(ev->u.send_pdu.sid, 
> ev->u.send_pdu.cid);
> - if (conn)
> + if (conn) {
> + mutex_lock(_mutex);
>   ev->r.retcode = transport->send_pdu(conn,
>   (struct iscsi_hdr*)((char*)ev + sizeof(*ev)),
>   (char*)ev + sizeof(*ev) + 
> ev->u.send_pdu.hdr_size,
>   ev->u.send_pdu.data_size);
> + mutex_unlock(_mutex);
> + }
>   else
>   err = -EINVAL;
>   break;
> 

My question above is for my own information, so I'll still say:

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/eb7a3a10-bb04-f601-a01b-c50f482474fa%40suse.com.

Re: PATCH] iscsi:report unbind session event when the target has been removed

[Lee Duncan]

On 3/24/20 12:52 AM, Wu Bo wrote:
> The daemon is restarted or crashed while logging out of a session.
> The unbind session event sent by the kernel is not be processed or be lost.
> When the daemon runs again, the session will never be able to logout.
> 
> After executing the logout again, the daemon is waiting for the unbind
> event message.
> The kernel status has been logged out and the event will not be sent again.
> 
> #iscsiadm -m node iqn.xxx -p xx.xx.xx.xx -u &
> #service iscsid restart
> 
> when iscsid restart done. logout session again report error:
> #iscsiadm -m node iqn.x -p xx.xx.xx.xx -u
> Logging out of session [sid: 6, target: iqn.x, portal:
> xx.xx.xx.xx,3260]
> iscsiadm: Could not logout of [sid: 6, target: iscsiadm -m node
> iqn.x, portal: xx.xx.xx.xx,3260].
> iscsiadm: initiator reported error (9 - internal error)
> iscsiadm: Could not logout of all requested sessions
> 
> Signed-off-by: Wu Bo 
> ---
>  drivers/scsi/scsi_transport_iscsi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/scsi_transport_iscsi.c
> b/drivers/scsi/scsi_transport_iscsi.c
> index dfc726f..443ace0 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -2012,7 +2012,7 @@ static void __iscsi_unbind_session(struct
> work_struct *work)
>     if (session->target_id == ISCSI_MAX_TARGET) {
>     spin_unlock_irqrestore(>lock, flags);
>     mutex_unlock(>mutex);
> -   return;
> +   goto unbind_session_exit;
>     }
> 
>     target_id = session->target_id;
> @@ -2024,6 +2024,8 @@ static void __iscsi_unbind_session(struct
> work_struct *work)
>     ida_simple_remove(_sess_ida, target_id);
> 
>     scsi_remove_target(>dev);
> +
> +unbind_session_exit:
>     iscsi_session_event(session, ISCSI_KEVENT_UNBIND_SESSION);
>     ISCSI_DBG_TRANS_SESSION(session, "Completed target removal\n");
>  }
> -- 
> 1.8.3.1
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/12f71fbf-746a-deea-aa93-e9f06c325dbf%40suse.com.

Re:

[Lee Duncan]

On 3/27/20 2:20 AM, chenanq...@oppo.com wrote:
> From: Chen Anqing 
> To: Lee Duncan 
> Cc: Chris Leech ,
> "James E . J . Bottomley" ,
> "Martin K . Petersen" ,
> ceph-de...@vger.kernel.org,
> open-iscsi@googlegroups.com,
> linux-s...@vger.kernel.org,
> linux-ker...@vger.kernel.org,
> chenanq...@oppo.com
> Subject: [PATCH] scsi: libiscsi: we should take compound page into account 
> also
> Date: Fri, 27 Mar 2020 05:20:01 -0400
> Message-Id: <20200327092001.56879-1-chenanq...@oppo.com>
> X-Mailer: git-send-email 2.18.2
> 
> the patch is occur at a real crash,which slab is
> come from a compound page,so we need take the compound page
> into account also.
> fixed commit 08b11eaccfcf ("scsi: libiscsi: fall back to
> sendmsg for slab pages").
> 
> Signed-off-by: Chen Anqing 
> ---
>  drivers/scsi/libiscsi_tcp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c
> index 6ef93c7af954..98304e5e1f6f 100644
> --- a/drivers/scsi/libiscsi_tcp.c
> +++ b/drivers/scsi/libiscsi_tcp.c
> @@ -128,7 +128,8 @@ static void iscsi_tcp_segment_map(struct iscsi_segment 
> *segment, int recv)
>  * coalescing neighboring slab objects into a single frag which
>  * triggers one of hardened usercopy checks.
>  */
> -   if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)))
> +   if (!recv && page_count(sg_page(sg)) >= 1 &&
> +   !PageSlab(compound_head(sg_page(sg
> return;
> 
> if (recv) {
> --
> 2.18.2
> 


This is missing a proper subject ...

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/5462bc04-8409-a0c3-628f-640d1c92b8c6%40suse.com.

Re: [PATCH] scsi:libiscsi:Fix an error count for active session

[Lee Duncan]

On 3/24/20 11:53 PM, wubo (T) wrote:
> From: Wu Bo 
> 
> Fix an error count for active session if the total_cmds is invalid 
> on the function iscsi_session_setup().
> decrement the number of active sessions before the func return.
> 
> Signed-off-by: Wu Bo 
> ---
>  drivers/scsi/libiscsi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index 70b99c0..b7158eb 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -2771,7 +2771,7 @@ struct iscsi_cls_session *
>"must be a power of 2.\n", total_cmds);
> total_cmds = rounddown_pow_of_two(total_cmds);
> if (total_cmds < ISCSI_TOTAL_CMDS_MIN)
> -   return NULL;
> +   goto dec_session_count;
> printk(KERN_INFO "iscsi: Rounding can_queue to %d.\n",
>total_cmds);
> }
> --
> 1.8.3.1
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/d4f7d5e1-1695-488e-2fee-ab562173d079%40suse.com.

Re: [PATCH RESEND v4] iscsi: Report connection state on sysfs

[Lee Duncan]

atic umode_t iscsi_conn_attr_is_visible(struct 
> kobject *kobj,
>   param = ISCSI_PARAM_TCP_RECV_WSF;
>   else if (attr == _attr_conn_local_ipaddr.attr)
>   param = ISCSI_PARAM_LOCAL_IPADDR;
> + else if (attr == _attr_conn_state.attr)
> + return S_IRUGO;
>   else {
>   WARN_ONCE(1, "Invalid conn attr");
>   return 0;
> diff --git a/include/scsi/scsi_transport_iscsi.h 
> b/include/scsi/scsi_transport_iscsi.h
> index fa8814245796..bdcb6d69d154 100644
> --- a/include/scsi/scsi_transport_iscsi.h
> +++ b/include/scsi/scsi_transport_iscsi.h
> @@ -188,6 +188,13 @@ extern void iscsi_ping_comp_event(uint32_t host_no,
> uint32_t status, uint32_t pid,
> uint32_t data_size, uint8_t *data);
>  
> +/* iscsi class connection state */
> +enum iscsi_connection_state {
> + ISCSI_CONN_UP = 0,
> + ISCSI_CONN_DOWN,
> + ISCSI_CONN_FAILED,
> +};
> +
>  struct iscsi_cls_conn {
>   struct list_head conn_list; /* item in connlist */
>   struct list_head conn_list_err; /* item in connlist_err */
> @@ -198,6 +205,7 @@ struct iscsi_cls_conn {
>   struct iscsi_endpoint *ep;
>  
>   struct device dev;  /* sysfs transport/container device */
> + enum iscsi_connection_state state;
>  };
>  
>  #define iscsi_dev_to_conn(_dev) \
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/2caa57c1-e1e2-3bb2-29f4-1c215016fca1%40suse.com.

Re: [PATCH] scsi: Replace zero-length array with flexible-array member

[Lee Duncan]

8f984 100644
> --- a/include/scsi/scsi_host.h
> +++ b/include/scsi/scsi_host.h
> @@ -682,7 +682,7 @@ struct Scsi_Host {
>* and also because some compilers (m68k) don't automatically force
>* alignment to a long boundary.
>*/
> - unsigned long hostdata[0]  /* Used for storage of host specific stuff */
> + unsigned long hostdata[]  /* Used for storage of host specific stuff */
>   __attribute__ ((aligned (sizeof(unsigned long;
>  };
>  
> diff --git a/include/scsi/scsi_ioctl.h b/include/scsi/scsi_ioctl.h
> index 4fe69d863b5d..b465799f4d2d 100644
> --- a/include/scsi/scsi_ioctl.h
> +++ b/include/scsi/scsi_ioctl.h
> @@ -27,7 +27,7 @@ struct scsi_device;
>  typedef struct scsi_ioctl_command {
>   unsigned int inlen;
>   unsigned int outlen;
> - unsigned char data[0];
> + unsigned char data[];
>  } Scsi_Ioctl_Command;
>  
>  typedef struct scsi_idlun {
> diff --git a/include/scsi/srp.h b/include/scsi/srp.h
> index 9220758d5087..177d8026e96f 100644
> --- a/include/scsi/srp.h
> +++ b/include/scsi/srp.h
> @@ -109,7 +109,7 @@ struct srp_direct_buf {
>  struct srp_indirect_buf {
>   struct srp_direct_buf   table_desc;
>   __be32  len;
> - struct srp_direct_buf   desc_list[0];
> + struct srp_direct_buf   desc_list[];
>  } __attribute__((packed));
>  
>  /* Immediate data buffer descriptor as defined in SRP2. */
> @@ -244,7 +244,7 @@ struct srp_cmd {
>   u8  reserved4;
>   u8  add_cdb_len;
>   u8  cdb[16];
> - u8  add_data[0];
> + u8  add_data[];
>  };
>  
>  enum {
> @@ -274,7 +274,7 @@ struct srp_rsp {
>   __be32  data_in_res_cnt;
>   __be32  sense_data_len;
>   __be32  resp_data_len;
> - u8  data[0];
> + u8  data[];
>  } __attribute__((packed));
>  
>  struct srp_cred_req {
> @@ -306,7 +306,7 @@ struct srp_aer_req {
>   struct scsi_lun lun;
>   __be32  sense_data_len;
>   u32 reserved3;
> - u8  sense_data[0];
> + u8  sense_data[];
>  } __attribute__((packed));
>  
>  struct srp_aer_rsp {
> diff --git a/include/uapi/scsi/scsi_bsg_fc.h b/include/uapi/scsi/scsi_bsg_fc.h
> index 3ae65e93235c..7f5930801f72 100644
> --- a/include/uapi/scsi/scsi_bsg_fc.h
> +++ b/include/uapi/scsi/scsi_bsg_fc.h
> @@ -209,7 +209,7 @@ struct fc_bsg_host_vendor {
>   __u64 vendor_id;
>  
>   /* start of vendor command area */
> - __u32 vendor_cmd[0];
> + __u32 vendor_cmd[];
>  };
>  
>  /* Response:
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/b44f60b7-3091-592e-b319-a929bcd19486%40suse.com.

Re: [PATCH RESEND v4] iscsi: Perform connection failure entirely in kernel space

[Lee Duncan]

On Jan 24, 2020, at 10:19 PM, Gabriel Krisman Bertazi  
wrote:
> 
> From: Bharath Ravi 
> 
> Hi Lee,
> 
> Martin asked for you to re-review this patch before he applies it, since
> there was a small change from v3 after you acked it.  The change is that
> we started to protect the list_empty() verification with the spin lock
> on session destruction.
> 
> For that reason, I dropped your reviewed-by.  Can you please take
> another look so we can have this merged?
> 
> Thanks,

I’m sorry if it didn’t get through, but I sent a Reviewed-by update and the end 
of last week.

I looked over the updates, and I said that they look good to me, and I said 
please re-add my:

Reviewed-by: Lee Duncan mailto:ldun...@suse.com>>


> 
> -- >8 -- 
> 
> Connection failure processing depends on a daemon being present to (at
> least) stop the connection and start recovery.  This is a problem on a
> multipath scenario, where if the daemon failed for whatever reason, the
> SCSI path is never marked as down, multipath won't perform the
> failover and IO to the device will be forever waiting for that
> connection to come back.
> 
> This patch performs the connection failure entirely inside the kernel.
> This way, the failover can happen and pending IO can continue even if
> the daemon is dead. Once the daemon comes alive again, it can execute
> recovery procedures if applicable.
> 
> Changes since v3:
>  - Protect list_empty with connlock on session destroy
> 
> Changes since v2:
>  - Don't hold rx_mutex for too long at once
> 
> Changes since v1:
>  - Remove module parameter.
>  - Always do kernel-side stop work.
>  - Block recovery timeout handler if system is dying.
>  - send a CONN_TERM stop if the system is dying.
> 
> Cc: Mike Christie 
> Cc: Lee Duncan 
> Cc: Bart Van Assche 
> Co-developed-by: Dave Clausen 
> Signed-off-by: Dave Clausen 
> Co-developed-by: Nick Black 
> Signed-off-by: Nick Black 
> Co-developed-by: Vaibhav Nagarnaik 
> Signed-off-by: Vaibhav Nagarnaik 
> Co-developed-by: Anatol Pomazau 
> Signed-off-by: Anatol Pomazau 
> Co-developed-by: Tahsin Erdogan 
> Signed-off-by: Tahsin Erdogan 
> Co-developed-by: Frank Mayhar 
> Signed-off-by: Frank Mayhar 
> Co-developed-by: Junho Ryu 
> Signed-off-by: Junho Ryu 
> Co-developed-by: Khazhismel Kumykov 
> Signed-off-by: Khazhismel Kumykov 
> Reviewed-by: Reviewed-by: Khazhismel Kumykov 
> Signed-off-by: Bharath Ravi 
> Co-developed-by: Gabriel Krisman Bertazi 
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
> drivers/scsi/scsi_transport_iscsi.c | 68 +
> include/scsi/scsi_transport_iscsi.h |  1 +
> 2 files changed, 69 insertions(+)
> 
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> index 271afea654e2..ba6cfaf71aef 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -86,6 +86,12 @@ struct iscsi_internal {
>   struct transport_container session_cont;
> };
> 
> +/* Worker to perform connection failure on unresponsive connections
> + * completely in kernel space.
> + */
> +static void stop_conn_work_fn(struct work_struct *work);
> +static DECLARE_WORK(stop_conn_work, stop_conn_work_fn);
> +
> static atomic_t iscsi_session_nr; /* sysfs session id for next new session */
> static struct workqueue_struct *iscsi_eh_timer_workq;
> 
> @@ -1611,6 +1617,7 @@ static DEFINE_MUTEX(rx_queue_mutex);
> static LIST_HEAD(sesslist);
> static DEFINE_SPINLOCK(sesslock);
> static LIST_HEAD(connlist);
> +static LIST_HEAD(connlist_err);
> static DEFINE_SPINLOCK(connlock);
> 
> static uint32_t iscsi_conn_get_sid(struct iscsi_cls_conn *conn)
> @@ -2247,6 +2254,7 @@ iscsi_create_conn(struct iscsi_cls_session *session, 
> int dd_size, uint32_t cid)
> 
>   mutex_init(>ep_mutex);
>   INIT_LIST_HEAD(>conn_list);
> + INIT_LIST_HEAD(>conn_list_err);
>   conn->transport = transport;
>   conn->cid = cid;
> 
> @@ -2293,6 +2301,7 @@ int iscsi_destroy_conn(struct iscsi_cls_conn *conn)
> 
>   spin_lock_irqsave(, flags);
>   list_del(>conn_list);
> + list_del(>conn_list_err);
>   spin_unlock_irqrestore(, flags);
> 
>   transport_unregister_device(>dev);
> @@ -2407,6 +2416,51 @@ int iscsi_offload_mesg(struct Scsi_Host *shost,
> }
> EXPORT_SYMBOL_GPL(iscsi_offload_mesg);
> 
> +static void stop_conn_work_fn(struct work_struct *work)
> +{
> + struct iscsi_cls_conn *conn, *tmp;
> + unsigned long flags;
> + LIST_HEAD(recovery_list);
> +
> + spin_lock_irqsave(, flags);
> + if (list_empty(_err)) {
> + spin_unlock_irqrest

Re: [PATCH RESEND] iscsi: Don't destroy session if there are outstanding connections

[Lee Duncan]

gt; b/drivers/scsi/scsi_transport_iscsi.c
>> index ed8d9709b9b9..271afea654e2 100644
>> --- a/drivers/scsi/scsi_transport_iscsi.c
>> +++ b/drivers/scsi/scsi_transport_iscsi.c
>> @@ -2947,6 +2947,24 @@ iscsi_set_path(struct iscsi_transport *transport, 
>> struct iscsi_uevent *ev)
>>  return err;
>>  }
>>  
>> +static int iscsi_session_has_conns(int sid)
>> +{
>> +struct iscsi_cls_conn *conn;
>> +unsigned long flags;
>> +int found = 0;
>> +
>> +spin_lock_irqsave(, flags);
>> +list_for_each_entry(conn, , conn_list) {
>> +if (iscsi_conn_get_sid(conn) == sid) {
>> +found = 1;
>> +break;
>> +}
>> +}
>> +spin_unlock_irqrestore(, flags);
>> +
>> +return found;
>> +}
>> +
>>  static int
>>  iscsi_set_iface_params(struct iscsi_transport *transport,
>> struct iscsi_uevent *ev, uint32_t len)
>> @@ -3524,10 +3542,12 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct 
>> nlmsghdr *nlh, uint32_t *group)
>>  break;
>>  case ISCSI_UEVENT_DESTROY_SESSION:
>>  session = iscsi_session_lookup(ev->u.d_session.sid);
>> -if (session)
>> -transport->destroy_session(session);
>> -else
>> +if (!session)
>>  err = -EINVAL;
>> +else if (iscsi_session_has_conns(ev->u.d_session.sid))
>> +err = -EBUSY;
>> +else
>> +transport->destroy_session(session);
>>  break;
>>  case ISCSI_UEVENT_UNBIND_SESSION:
>>  session = iscsi_session_lookup(ev->u.d_session.sid);
>> -- 
>> 2.24.1
> 

Please add my:

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/d0278122-729b-b921-1343-40a23fb315f7%40suse.com.

Re: Who know more about this issue for iscsid?

[Lee Duncan]

On Jan 11, 2020, at 7:28 PM, can zhu  wrote:
> 
> For the initiator.

Then who set up your targets, and how are they set up?

> 
> Lee Duncan mailto:leeman.dun...@gmail.com>> 
> 于2020年1月12日周日 上午11:16写道：
> 
> 
>> On Jan 11, 2020, at 7:15 PM, can zhu > <mailto:zhucan@gmail.com>> wrote:
>> 
>> Hmmm, I use the default config, I hadn't do other sets for it.
> 
> For? For the initiator, or the target?
> 
>> 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/6BF4CC94-0C36-4E65-B8FB-98BFBB51FC92%40gmail.com.

Re: how it works

[Lee Duncan]

On Jan 11, 2020, at 11:26 AM, Bobby  wrote:
> 
> Hi ,
> 
> Thanks for your patience  regarding my questions. Because after I had dug 
> (digged) very older posts, I realized 
> many of the older posts already had answers for many of my earlier questions 
> :). After your couple of answers and going 
> through old posts, I have a better understanding of user land and kernel land.

Excellent.

> 
> Now one more point.
> 
> Kernel land: 
> While we are at kernel land, I have a confusion on that.
> AFAIK in linux kernel, the linux block layer is a glue that, on the one hand, 
> allows applications to access 
> diverse storage devices 
> in a uniform way, and on the other hand,
> provides storage devices and drivers with a single point of entry from all 
> applications.
> I mean this Linux OS (host) block layer is the most
> critical part of the I/O hierarchy, as it orchestrates the I/O
> requests from different applications to the underlying storage.
> 
> Question:
> So in context of Open-iSCSI, where does the user-land interacts the block 
> layer in the kernel land? I 
> mean, when it comes to kernel land, why we are considering only 
> scsi_transport_iscsi.c and iscsi_tcp.c codes? Shouldn't
> the block request go through block layer?
> 
> As always, thanks in advance :)
> 
> 

The iscsi initiator (open-iscsi) acts as an HBA, in effect, in the block system.

The layer above the block layer (conceptually) are the disc or tape drivers.The 
block layer presents an abstract interface to them, so that they only have to 
deal with putting bits in blocks, or getting bits from blocks.

The layer below the block layer, on the other hand, gets requests to put bits 
in blocks or to get bits from blocks, and has to deal with how to actually 
implement that, given where the bits live. For a local disc, this is an HBA 
adapter driver. For iSCSI, this is actually a transport rather than an HBA. 
There are several transports, for example iSER (Infiniband) is another.

I hope that helps. 
— 
Lee


-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/ABCA782A-1508-45D5-9283-933FE7855CF4%40gmail.com.

Re: Who know more about this issue for iscsid?

[Lee Duncan]

> On Jan 11, 2020, at 7:15 PM, can zhu  wrote:
> 
> Hmmm, I use the default config, I hadn't do other sets for it.

For? For the initiator, or the target?

> 
> 在 2020年1月12日星期日 UTC+8上午11:13:31，The Lee-Man写道：
> On Jan 11, 2020, at 7:41 AM, can zhu > wrote:
>> 
>> I did not set the auth.
>> 
> 
> Please share how your systems is configured. Did you set up your targets?
> 
> Assuming you set up your targets, and they are on targetcli, can you share 
> your configuration file?
> 
> Also, can you ensure you have no auth set up on your initiator?
> 
> — 
> Lee
> 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/1EB02856-CF99-4B41-A6B0-7A89350162E3%40gmail.com.

Re: Who know more about this issue for iscsid?

[Lee Duncan]

On Jan 11, 2020, at 7:41 AM, can zhu  wrote:
> 
> I did not set the auth.
> 

Please share how your systems is configured. Did you set up your targets?

Assuming you set up your targets, and they are on targetcli, can you share your 
configuration file?

Also, can you ensure you have no auth set up on your initiator?

— 
Lee


-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/57585076-3602-47C4-92CD-5510CA87E4EF%40gmail.com.

Re: Open-iSCSI in research paper

[Lee Duncan]

On Jan 2, 2020, at 8:51 AM, Bobby  wrote:
> 
> One of the good things about this forum is, you always get helpthanks for 
> the reply :-)
> 
> I will soon have some questions regarding the user-land and kernel 
> driver(s) :-)
> 
> Regarding microbenchmarks, I think this one is good 
> https://fio.readthedocs.io/en/latest/fio_doc.html 
> .
> 
> What do you think?
> 
> 

Actually, I interpreted their lack of supplying a benchmark name to mean that 
they had rolled their own.

Fio is a well-known benchmark. I’m not an expert on it so I can’t comment on 
it’s features and shortcomings, but I’m sure you could get some valuable 
numbers out of it. First, you have to decide what you want to measure. Is it 
IOPs, it is throughput, is it latency? Are you trying to simulate a specific 
workload (since that’s what really matters, in the end), or just get some 
numbers?

— 
Lee


-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/FCB787D9-40BE-4164-A726-05C66249A8B0%40gmail.com.

Re: [PATCH v3] iscsi: Perform connection failure entirely in kernel space

[Lee Duncan]

On 12/26/19 12:47 PM, Gabriel Krisman Bertazi wrote:
> From: Bharath Ravi 
> 
> Connection failure processing depends on a daemon being present to (at
> least) stop the connection and start recovery.  This is a problem on a
> multipath scenario, where if the daemon failed for whatever reason, the
> SCSI path is never marked as down, multipath won't perform the
> failover and IO to the device will be forever waiting for that
> connection to come back.
> 
> This patch performs the connection failure entirely inside the kernel.
> This way, the failover can happen and pending IO can continue even if
> the daemon is dead. Once the daemon comes alive again, it can execute
> recovery procedures if applicable.
> 
> Changes since v2:
>   - Don't hold rx_mutex for too long at once
> 
> Changes since v1:
>   - Remove module parameter.
>   - Always do kernel-side stop work.
>   - Block recovery timeout handler if system is dying.
>   - send a CONN_TERM stop if the system is dying.
> 
> Cc: Mike Christie 
> Cc: Lee Duncan 
> Cc: Bart Van Assche 
> Co-developed-by: Dave Clausen 
> Signed-off-by: Dave Clausen 
> Co-developed-by: Nick Black 
> Signed-off-by: Nick Black 
> Co-developed-by: Vaibhav Nagarnaik 
> Signed-off-by: Vaibhav Nagarnaik 
> Co-developed-by: Anatol Pomazau 
> Signed-off-by: Anatol Pomazau 
> Co-developed-by: Tahsin Erdogan 
> Signed-off-by: Tahsin Erdogan 
> Co-developed-by: Frank Mayhar 
> Signed-off-by: Frank Mayhar 
> Co-developed-by: Junho Ryu 
> Signed-off-by: Junho Ryu 
> Co-developed-by: Khazhismel Kumykov 
> Signed-off-by: Khazhismel Kumykov 
> Signed-off-by: Bharath Ravi 
> Co-developed-by: Gabriel Krisman Bertazi 
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
>  drivers/scsi/scsi_transport_iscsi.c | 63 +
>  include/scsi/scsi_transport_iscsi.h |  1 +
>  2 files changed, 64 insertions(+)
> 
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> index 271afea654e2..c6db6ded60a1 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -86,6 +86,12 @@ struct iscsi_internal {
>   struct transport_container session_cont;
>  };
>  
> +/* Worker to perform connection failure on unresponsive connections
> + * completely in kernel space.
> + */
> +static void stop_conn_work_fn(struct work_struct *work);
> +static DECLARE_WORK(stop_conn_work, stop_conn_work_fn);
> +
>  static atomic_t iscsi_session_nr; /* sysfs session id for next new session */
>  static struct workqueue_struct *iscsi_eh_timer_workq;
>  
> @@ -1611,6 +1617,7 @@ static DEFINE_MUTEX(rx_queue_mutex);
>  static LIST_HEAD(sesslist);
>  static DEFINE_SPINLOCK(sesslock);
>  static LIST_HEAD(connlist);
> +static LIST_HEAD(connlist_err);
>  static DEFINE_SPINLOCK(connlock);
>  
>  static uint32_t iscsi_conn_get_sid(struct iscsi_cls_conn *conn)
> @@ -2247,6 +2254,7 @@ iscsi_create_conn(struct iscsi_cls_session *session, 
> int dd_size, uint32_t cid)
>  
>   mutex_init(>ep_mutex);
>   INIT_LIST_HEAD(>conn_list);
> + INIT_LIST_HEAD(>conn_list_err);
>   conn->transport = transport;
>   conn->cid = cid;
>  
> @@ -2293,6 +2301,7 @@ int iscsi_destroy_conn(struct iscsi_cls_conn *conn)
>  
>   spin_lock_irqsave(, flags);
>   list_del(>conn_list);
> + list_del(>conn_list_err);
>   spin_unlock_irqrestore(, flags);
>  
>   transport_unregister_device(>dev);
> @@ -2407,6 +2416,51 @@ int iscsi_offload_mesg(struct Scsi_Host *shost,
>  }
>  EXPORT_SYMBOL_GPL(iscsi_offload_mesg);
>  
> +static void stop_conn_work_fn(struct work_struct *work)
> +{
> + struct iscsi_cls_conn *conn, *tmp;
> + unsigned long flags;
> + LIST_HEAD(recovery_list);
> +
> + spin_lock_irqsave(, flags);
> + if (list_empty(_err)) {
> + spin_unlock_irqrestore(, flags);
> + return;
> + }
> + list_splice_init(_err, _list);
> + spin_unlock_irqrestore(, flags);
> +
> + list_for_each_entry_safe(conn, tmp, _list, conn_list_err) {
> + uint32_t sid = iscsi_conn_get_sid(conn);
> + struct iscsi_cls_session *session;
> +
> + mutex_lock(_queue_mutex);
> +
> + session = iscsi_session_lookup(sid);
> + if (session) {
> + if (system_state != SYSTEM_RUNNING) {
> + session->recovery_tmo = 0;
> + conn->transport->stop_conn(conn,
> +STOP_CONN_TERM);
> + } else {
> +   

Re: [PATCH V4] scsi: avoid potential deadlock in iscsi_if_rx func

[Lee Duncan]

On 12/9/19 3:11 PM, Martin K. Petersen wrote:
> 
> wubo,
> 
>> In iscsi_if_rx func, after receiving one request through
>> iscsi_if_recv_msg func, iscsi_if_send_reply will be called to try to
>> reply the request in do-loop.  If the return of iscsi_if_send_reply
>> func return -EAGAIN all the time, one deadlock will occur.
>>
>> For example, a client only send msg without calling recvmsg func, then
>> it will result in the watchdog soft lockup.  The details are given as
>> follows,
> 
>> Signed-off-by: Bo Wu 
>> Reviewed-by: Zhiqiang Liu 
>> Reviewed-by: Lee Duncan 
> 
> I haven't seen a Reviewed-by: from Lee on this patch.
> 

Martin:

My sincere apologies. I told wubo I had already reviewed the patch, so
he didn't need another Reviewed-by from me. I see I was wrong.

Please consider my:

Reviewed-by: Lee Duncan 

in the patch to be re-verified.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/ccda52ac-2ea7-b0d2-e36e-08f162569c7c%40suse.com.

Re: [PATCH] iscsi: Perform connection failure entirely in kernel space

[Lee Duncan]

On 12/9/19 10:20 AM, Gabriel Krisman Bertazi wrote:
> From: Bharath Ravi 
> 
> Connection failure processing depends on a daemon being present to (at
> least) stop the connection and start recovery.  This is a problem on a
> multipath scenario, where if the daemon failed for whatever reason, the
> SCSI path is never marked as down, multipath won't perform the
> failover and IO to the device will be forever waiting for that
> connection to come back.
> 
> This patch implements an optional feature in the iscsi module, to
> perform the connection failure inside the kernel.  This way, the
> failover can happen and pending IO can continue even if the daemon is
> dead. Once the daemon comes alive again, it can perform recovery
> procedures if applicable.


I don't suppose you've tested how this plays with the daemon, when present?


> 
> Co-developed-by: Dave Clausen 
> Signed-off-by: Dave Clausen 
> Co-developed-by: Nick Black 
> Signed-off-by: Nick Black 
> Co-developed-by: Vaibhav Nagarnaik 
> Signed-off-by: Vaibhav Nagarnaik 
> Co-developed-by: Anatol Pomazau 
> Signed-off-by: Anatol Pomazau 
> Co-developed-by: Tahsin Erdogan 
> Signed-off-by: Tahsin Erdogan 
> Co-developed-by: Frank Mayhar 
> Signed-off-by: Frank Mayhar 
> Co-developed-by: Junho Ryu 
> Signed-off-by: Junho Ryu 
> Co-developed-by: Khazhismel Kumykov 
> Signed-off-by: Khazhismel Kumykov 
> Signed-off-by: Bharath Ravi 
> Co-developed-by: Gabriel Krisman Bertazi 
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
>  drivers/scsi/scsi_transport_iscsi.c | 46 +
>  include/scsi/scsi_transport_iscsi.h |  1 +
>  2 files changed, 47 insertions(+)
> 
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> index 417b868d8735..7251b2b5b272 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -36,6 +36,12 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(iscsi_dbg_session);
>  EXPORT_TRACEPOINT_SYMBOL_GPL(iscsi_dbg_tcp);
>  EXPORT_TRACEPOINT_SYMBOL_GPL(iscsi_dbg_sw_tcp);
>  
> +static bool kern_conn_failure;
> +module_param(kern_conn_failure, bool, S_IRUGO|S_IWUSR);
> +MODULE_PARM_DESC(kern_conn_failure,
> +  "Allow the kernel to detect and disable broken connections "
> +  "without requiring userspace intervention");
> +
>  static int dbg_session;
>  module_param_named(debug_session, dbg_session, int,
>  S_IRUGO | S_IWUSR);
> @@ -84,6 +90,12 @@ struct iscsi_internal {
>   struct transport_container session_cont;
>  };
>  
> +/* Worker to perform connection failure on unresponsive connections
> + * completely in kernel space.
> + */
> +static void stop_conn_work_fn(struct work_struct *work);
> +static DECLARE_WORK(stop_conn_work, stop_conn_work_fn);
> +
>  static atomic_t iscsi_session_nr; /* sysfs session id for next new session */
>  static struct workqueue_struct *iscsi_eh_timer_workq;
>  
> @@ -1609,6 +1621,7 @@ static DEFINE_MUTEX(rx_queue_mutex);
>  static LIST_HEAD(sesslist);
>  static DEFINE_SPINLOCK(sesslock);
>  static LIST_HEAD(connlist);
> +static LIST_HEAD(connlist_err);
>  static DEFINE_SPINLOCK(connlock);
>  
>  static uint32_t iscsi_conn_get_sid(struct iscsi_cls_conn *conn)
> @@ -2245,6 +2258,7 @@ iscsi_create_conn(struct iscsi_cls_session *session, 
> int dd_size, uint32_t cid)
>  
>   mutex_init(>ep_mutex);
>   INIT_LIST_HEAD(>conn_list);
> + INIT_LIST_HEAD(>conn_list_err);
>   conn->transport = transport;
>   conn->cid = cid;
>  
> @@ -2291,6 +2305,7 @@ int iscsi_destroy_conn(struct iscsi_cls_conn *conn)
>  
>   spin_lock_irqsave(, flags);
>   list_del(>conn_list);
> + list_del(>conn_list_err);
>   spin_unlock_irqrestore(, flags);
>  
>   transport_unregister_device(>dev);
> @@ -2405,6 +2420,28 @@ int iscsi_offload_mesg(struct Scsi_Host *shost,
>  }
>  EXPORT_SYMBOL_GPL(iscsi_offload_mesg);
>  
> +static void stop_conn_work_fn(struct work_struct *work)
> +{
> + struct iscsi_cls_conn *conn, *tmp;
> + unsigned long flags;
> + LIST_HEAD(recovery_list);
> +
> + spin_lock_irqsave(, flags);
> + if (list_empty(_err)) {
> + spin_unlock_irqrestore(, flags);
> + return;
> + }
> + list_splice_init(_err, _list);
> + spin_unlock_irqrestore(, flags);
> +
> + mutex_lock(_queue_mutex);
> + list_for_each_entry_safe(conn, tmp, _list, conn_list_err) {
> + conn->transport->stop_conn(conn, STOP_CONN_RECOVER);
> + list_del_init(>conn_list_err);
> + }
> + mutex_unlock(_queue_mutex);
> +}
> +
>  void iscsi_conn_error_event(struct iscsi_cls_conn *conn, enum iscsi_err 
> error)
>  {
>   struct nlmsghdr *nlh;
> @@ -2412,6 +2449,15 @@ void iscsi_conn_error_event(struct iscsi_cls_conn 
> *conn, enum iscsi_err error)
>   struct iscsi_uevent *ev;
>   struct iscsi_internal *priv;
>   int len = nlmsg_total_size(sizeof(*ev));
> + unsigned long flags;
> +
> + if 

Re: [PATCH] iscsi: Don't send data to unbinded connection

[Lee Duncan]

On 11/15/19 4:47 PM, Gabriel Krisman Bertazi wrote:
> From: Anatol Pomazau 
> 
> If a faulty initiator fails to bind the socket to the iSCSI connection
> before emitting a command, for instance, a subsequent send_pdu, it will
> crash the kernel due to a null pointer dereference in sock_sendmsg(), as
> shown in the log below.  This make sure the bind succeeded before trying
> to use the socket.
> 
> BUG: kernel NULL pointer dereference, address: 0018
>  #PF: supervisor read access in kernel mode
>  #PF: error_code(0x) - not-present page
> PGD 0 P4D 0
> Oops:  [#1] SMP PTI
> CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.4.0-rc2.iscsi+ #13
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 
> 04/01/2014
> [   24.158246] Workqueue: iscsi_q_0 iscsi_xmitworker
> [   24.158883] RIP: 0010:apparmor_socket_sendmsg+0x5/0x20
> [...]
> [   24.161739] RSP: 0018:ab6440043ca0 EFLAGS: 00010282
> [   24.162400] RAX: 891c1c00 RBX: 89d53968 RCX: 
> 0001
> [   24.163253] RDX: 0030 RSI: ab6440043d00 RDI: 
> 
> [   24.164104] RBP: 0030 R08: 0030 R09: 
> 0030
> [   24.165166] R10: 893e66a0 R11: 0018 R12: 
> ab6440043d00
> [   24.166038] R13:  R14:  R15: 
> 9d5575a62e90
> [   24.166919] FS:  () GS:9d557db8() 
> knlGS:
> [   24.167890] CS:  0010 DS:  ES:  CR0: 80050033
> [   24.168587] CR2: 0018 CR3: 7a838000 CR4: 
> 06e0
> [   24.169451] DR0:  DR1:  DR2: 
> 
> [   24.170320] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [   24.171214] Call Trace:
> [   24.171537]  security_socket_sendmsg+0x3a/0x50
> [   24.172079]  sock_sendmsg+0x16/0x60
> [   24.172506]  iscsi_sw_tcp_xmit_segment+0x77/0x120
> [   24.173076]  iscsi_sw_tcp_pdu_xmit+0x58/0x170
> [   24.173604]  ? iscsi_dbg_trace+0x63/0x80
> [   24.174087]  iscsi_tcp_task_xmit+0x101/0x280
> [   24.174666]  iscsi_xmit_task+0x83/0x110
> [   24.175206]  iscsi_xmitworker+0x57/0x380
> [   24.175757]  ? __schedule+0x2a2/0x700
> [   24.176273]  process_one_work+0x1b5/0x360
> [   24.176837]  worker_thread+0x50/0x3c0
> [   24.177353]  kthread+0xf9/0x130
> [   24.177799]  ? process_one_work+0x360/0x360
> [   24.178401]  ? kthread_park+0x90/0x90
> [   24.178915]  ret_from_fork+0x35/0x40
> [   24.179421] Modules linked in:
> [   24.179856] CR2: 0018
> [   24.180327] ---[ end trace b4b7674b6df5f480 ]---
> 
> Co-developed-by: Frank Mayhar 
> Signed-off-by: Frank Mayhar 
> Co-developed-by: Bharath Ravi 
> Signed-off-by: Bharath Ravi 
> Co-developed-by: Khazhimsel Kumykov 
> Signed-off-by: Khazhimsel Kumykov 
> Signed-off-by: Anatol Pomazau 
> Co-developed-by: Gabriel Krisman Bertazi 
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
>  drivers/scsi/iscsi_tcp.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> index cea7fda1dd23..b5dd1caae5e9 100644
> --- a/drivers/scsi/iscsi_tcp.c
> +++ b/drivers/scsi/iscsi_tcp.c
> @@ -369,8 +369,16 @@ static int iscsi_sw_tcp_pdu_xmit(struct iscsi_task *task)
>  {
>   struct iscsi_conn *conn = task->conn;
>   unsigned int noreclaim_flag;
> + struct iscsi_tcp_conn *tcp_conn = conn->dd_data;
> + struct iscsi_sw_tcp_conn *tcp_sw_conn = tcp_conn->dd_data;
>   int rc = 0;
>  
> + if (!tcp_sw_conn->sock) {
> + iscsi_conn_printk(KERN_ERR, conn,
> +   "Transport not bound to socket!\n");
> + return -EINVAL;
> + }
> +
>   noreclaim_flag = memalloc_noreclaim_save();
>  
>   while (iscsi_sw_tcp_xmit_qlen(conn)) {
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/2b4a232e-add1-38a6-e86d-0192737f2fd9%40suse.com.

Re: [PATCH v3] scsi: avoid potential deadloop in iscsi_if_rx func

[Lee Duncan]

On 11/12/19 5:37 PM, Martin K. Petersen wrote:
> 
>> In iscsi_if_rx func, after receiving one request through
>> iscsi_if_recv_msg func, iscsi_if_send_reply will be called to try to
>> reply the request in do-loop. If the return of iscsi_if_send_reply
>> func return -EAGAIN all the time, one deadloop will occur.
>>  
>> For example, a client only send msg without calling recvmsg func, 
>> then it will result in the watchdog soft lockup. 
>> The details are given as follows,
> 
> Lee/Chris/Ulrich: Please review!
> 


Okay, after looking again at the thread, I do have some additional
feedback for the patch submitter.

You should put your "changes in V2, V3, ..." above the patch line (the
"-- " on a line by itself), not as part of the patch.

Also, as long as you are making one last round of changes, please change
"deadloop" to "deadlock" in your patch subject, as deadloop is not a word.

Lastly, the "Suggested-by" lines you added are fine, but that generally
means that person suggested the patch, not changes. For folks that
suggest changes, it's up to them to say they like or do not like your
changes after you make them, at which point they can add their
"Reviewed-by" tag if they wish.

Please feel free to send your patch to me directly, before publishing,
if you would like a review before publishing again.

-- 
Lee

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/e0ddba45-7fd4-a1e9-b1e8-d59a46316695%40suse.com.

Re: [PATCH v3] scsi: avoid potential deadloop in iscsi_if_rx func

[Lee Duncan]

On 11/12/19 5:37 PM, Martin K. Petersen wrote:
> 
>> In iscsi_if_rx func, after receiving one request through
>> iscsi_if_recv_msg func, iscsi_if_send_reply will be called to try to
>> reply the request in do-loop. If the return of iscsi_if_send_reply
>> func return -EAGAIN all the time, one deadloop will occur.
>>  
>> For example, a client only send msg without calling recvmsg func, 
>> then it will result in the watchdog soft lockup. 
>> The details are given as follows,
> 
> Lee/Chris/Ulrich: Please review!
> 

I believe I already added my Reviewed-by tag. Do you mean past that?
Perhaps I missed something.
-- 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/d0d2bcf7-9d9d-40f9-335d-ebcdafdf9969%40suse.com.

Re: [PATCH] scsi: avoid potential deadloop in iscsi_if_rx func

[Lee Duncan]

On 10/26/19 1:55 AM, wubo (T) wrote:
> From: Bo Wu 
> 
> In iscsi_if_rx func, after receiving one request through iscsi_if_recv_msg
> func,iscsi_if_send_reply will be called to try to reply the request in 
> do-loop. If the return of iscsi_if_send_reply func fails all the time, one
> deadloop will occur.
>  
> For example, a client only send msg without calling recvmsg func, then it
> will result in the watchdog soft lockup. The details are given as follows,
> 
> Details of the special case which can cause deadloop:
> sock_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ISCSI); 
> ... 
> retval = bind(sock_fd, (struct sock addr*) & src_addr, sizeof (src_addr); 
> ... 
> while (1) { 
>   state_smg = sendmsg(sock_fd, , 0); 
> } 
> // Note: recvmsg (sock_fd, & msg, 0) is not processed here. 
> close(sock_fd); 
> 
> watchdog: BUG: soft lockup - CPU#7 stuck for 22s! [netlink_test:253305]
> Sample time: 4000897528 ns(HZ: 250)
> Sample stat: 
> curr: user: 675503481560, nice: 321724050, sys: 448689506750, idle: 
> 4654054240530, iowait: 40885550700, irq: 14161174020, softirq: 8104324140, 
> st: 0
> deta: user: 0, nice: 0, sys: 3998210100, idle: 0, iowait: 0, irq: 1547170, 
> softirq: 242870, st: 0
> Sample softirq:
>   TIMER:992
>   SCHED:  8
> Sample irqstat:
>  irq2: delta   1003, curr:3103802, arch_timer
> CPU: 7 PID: 253305 Comm: netlink_test Kdump: loaded Tainted: G   OE   
>   
> Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
> pstate: 4045 (nZcv daif +PAN -UAO)
> pc : __alloc_skb+0x104/0x1b0
> lr : __alloc_skb+0x9c/0x1b0
> sp : 33603a30
> x29: 33603a30 x28: 02dd 
> x27: 800b34ced810 x26: 800ba7569f00 
> x25:  x24:  
> x23: 800f7c43f600 x22: 00480020 
> x21: 091d9000 x20: 800b34eff200 
> x19: 800ba7569f00 x18:  
> x17:  x16:  
> x15:  x14: 0001000101000100 
> x13: 00010101 x12: 010101010100 
> x11: 0001010101010001 x10: 02dd 
> x9 : 33603d58 x8 : 800b34eff400 
> x7 : 800ba7569200 x6 : 800b34eff400 
> x5 :  x4 :  
> x3 :  x2 : 0001 
> x1 : 800b34eff2c0 x0 : 0300 
> Call trace:
> __alloc_skb+0x104/0x1b0
> iscsi_if_rx+0x144/0x12bc [scsi_transport_iscsi]
> netlink_unicast+0x1e0/0x258
> netlink_sendmsg+0x310/0x378
> sock_sendmsg+0x4c/0x70
> sock_write_iter+0x90/0xf0
> __vfs_write+0x11c/0x190
> vfs_write+0xac/0x1c0
> ksys_write+0x6c/0xd8
> __arm64_sys_write+0x24/0x30
> el0_svc_common+0x78/0x130
> el0_svc_handler+0x38/0x78
> el0_svc+0x8/0xc
> 
> Here, we add one limit of retry times in do-loop to avoid the deadloop.
> 
> Signed-off-by: Bo Wu 
> Reviewed-by: Zhiqiang Liu 
> ---
>  drivers/scsi/scsi_transport_iscsi.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> index 417b868d8735..f377bfed6b0c 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -24,6 +24,8 @@
>  
>  #define ISCSI_TRANSPORT_VERSION "2.0-870"
>  
> +#define ISCSI_SEND_MAX_ALLOWED 10
> +
>  #define CREATE_TRACE_POINTS
>  #include 
>  
> @@ -3682,6 +3684,7 @@ iscsi_if_rx(struct sk_buff *skb)
>   struct nlmsghdr *nlh;
>   struct iscsi_uevent *ev;
>   uint32_t group;
> + int retries = ISCSI_SEND_MAX_ALLOWED;
>  
>   nlh = nlmsg_hdr(skb);
>   if (nlh->nlmsg_len < sizeof(*nlh) + sizeof(*ev) ||
> @@ -3710,8 +3713,11 @@ iscsi_if_rx(struct sk_buff *skb)
>   break;
>   if (ev->type == ISCSI_UEVENT_GET_CHAP && !err)
>   break;
> + if (retries <= 0)
> + break;
>   err = iscsi_if_send_reply(portid, nlh->nlmsg_type,
> ev, sizeof(*ev));
> + retries--;
>   } while (err < 0 && err != -ECONNREFUSED && err != -ESRCH);
>   skb_pull(skb, rlen);
>   }
> 

You could have used "if (--retries < 0)" (or some variation thereof) but
that may not be as clear, and certainly is only a nit. So I'm fine with
that.

But I would like to see some sort of error or even debug kernel message
if we time out waiting to receive a response. Otherwise, how will some
human diagnose this problem?

-- 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/92b221da-18a8-8b7b-0436-ca59088fd45b%40suse.com.

Re: AW: iscsiadm unable to connect to iscsd

[Lee Duncan]

What bug number? I’m the SUSE maintainer. :) 

--
Lee-Man Duncan
Sent from my iPhone, dude


> On Oct 1, 2019, at 10:39 AM,   wrote:
> 
> Thanks a lot, i forwarded this to suse, as they maintain the iscsi packages…
>  
> Von: open-iscsi@googlegroups.com  Im Auftrag von 
> The Lee-Man
> Gesendet: Montag, 30. September 2019 23:20
> An: open-iscsi 
> Betreff: Re: iscsiadm unable to connect to iscsd
>  
> See https://github.com/open-iscsi/open-iscsi/pull/174
> 
> On Friday, September 20, 2019 at 2:02:20 AM UTC-7, Dirk Laurenz wrote:
> Hi,
>  
> want to read the session stats for a connection, but iscsiadm claims not to 
> be able to connect to iscsd.
> I'm not sure how to debug this:
>  
> $host:/etc/iscsi # iscsiadm -m session
> tcp: [1] $IP1:3260,1032 $host1-lun01 (non-flash)
> tcp: [2] $IP2:3260,1032 $host2-lun01 (non-flash)
> tcp: [3] $IP3:3260,1 $host3:lun01 (non-flash)
> $host:/etc/iscsi # iscsiadm -m session -r 2 -s
> iscsiadm: Could not execute operation on all sessions: could not connect to 
> iscsid
>  
> any idea?
>  
> OS is SLES4SAP12 SP4
>  
> Regards,
>  
> Dirk
>  
> -- 
> You received this message because you are subscribed to the Google Groups 
> "open-iscsi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to open-iscsi+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/f4da4808-aa2a-4de5-ace3-8f8a072b6593%40googlegroups.com.
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "open-iscsi" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/open-iscsi/9B-cSJR8Tic/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> open-iscsi+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/open-iscsi/02d201d5787f%2432ff4eb0%2498fdec10%24%40laurenz.ws.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/EEA44DFF-A7FC-4967-B67D-94681CC65835%40gmail.com.

Re: [PATCH] scsi: use kzfree to free password

[Lee Duncan]

On 7/27/19 3:39 AM, Wang Xiayang wrote:

> Similar to commit 34bca9bbe7a8 ("cifs: Use kzfree() to free password"),
> password strings allocated for CHAP should be zero-ed before freed.
>
> Signed-off-by: Wang Xiayang 
> ---
>  drivers/scsi/libiscsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index ebd47c0cf9e9..67d66e6dbdb0 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -2854,8 +2854,8 @@ void iscsi_session_teardown(struct iscsi_cls_session 
> *cls_session)
>  
>   iscsi_remove_session(cls_session);
>  
> - kfree(session->password);
> - kfree(session->password_in);
> + kzfree(session->password);
> + kzfree(session->password_in);
>   kfree(session->username);
>   kfree(session->username_in);
>   kfree(session->targetname);

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/4d2430d7-8eec-2d52-263e-41bf468598e0%40suse.com.

Re: [PATCH] Check sk before sendpage

[Lee Duncan]

On 7/10/19 12:30 AM, Yang Bin wrote:

> From: " Yang Bin "
>
> Before xmit,iscsi may disconnect just now.
> So must check connection sock NULL or not,or kernel will crash for
> accessing NULL pointer.
>
> Signed-off-by: Yang Bin 
> ---
>  drivers/scsi/iscsi_tcp.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> index 7bedbe8..a59c49f 100644
> --- a/drivers/scsi/iscsi_tcp.c
> +++ b/drivers/scsi/iscsi_tcp.c
> @@ -264,6 +264,9 @@ static int iscsi_sw_tcp_xmit_segment(struct 
> iscsi_tcp_conn *tcp_conn,
>   unsigned int copied = 0;
>   int r = 0;
>  
> + if (!sk)
> + return -ENOTCONN;
> +
>   while (!iscsi_tcp_segment_done(tcp_conn, segment, 0, r)) {
>   struct scatterlist *sg;
>   unsigned int offset, copy;
>

If the socket can be closed right before iscsi_sw_tcp_xmit_segment() is
called, can it be called in the middle of sending segments? (In which
case the check would have to be in the while loop.)

-- 

Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/1bc364ff-5bff-47ac-611a-f75c43f4bd1b%40suse.com.
For more options, visit https://groups.google.com/d/optout.

Re: open scsi change -- 467946a945cc0f2432274a66e916959d5a5c3772

[Lee Duncan]

On 3/20/19 7:32 PM, Rao Shoaib wrote:
> Hi,

Hi! Please direct questions at the open-iscsi group on googlegroups, so
others can contribute to and/or benefit from the discussion.

> 
> In the commit of the above change you say
> 
> "But, make no
>     mistake, it is recommended not to retry forever, as it leaves
>     iscsid stuck in "iscsi_sysfs_for_each_session()" in iscsid.c:main(),
>     so iscsid never fully gets up and running."
> 
> I do not see how iscsid will get stuck as it forks and does not wait for
> the child to finish. Can you kindly explain it to me.
> 
> Regards,
> 
> Shoaib
> 
> 

TL;DR
=
That statement was partly incorrect. It's not that bad, but it's still bad.

DETAILS
===
There are two effects from letting the forked child process try forever
to recover a session, assuming that the session cannot or will not ever
be recovered:

1. If there are multiple sessions to be recovered, the recovery is done
in serial, so if the process tries forever to recover any particular
session, other sessions waiting in line behind it will never be
recovered. If there are thousands of sessions this would be bad.

NOTE: there is an option to do this in parallel, but that has never been
tested and is not enabled.

2. The systemd "state" will be "Ready"/"Syncing external sessions(s)"
until the resync completes, and "Ready"/"Ready to process requests" when
done.

In an environment where one expects each and every session to be
recovered, or else there's a problem, then retrying forever might make
sense. But in an environment like cloud computing, where sessions might
come and go, and you might never see that session again, retrying
forever is not good.

And, by the way, it only occurs when the service is stopped and
restarted, so if some session has "gone away" it may have gone away a
LONG time ago and is only discovered when the service/system restarts,
which sometimes is way too late to do much about it.

I prefer a system using iSNS where targets and initiators can get
notifications of changes, but such a configuration does not seem very
popular. Even so, if I had a product based on iscsi connections, I would
write some sort of daemon that periodically checked connections, kept
track of which ones went away as planned and which ones should be
retried and for how long. Sort of like the discovery daemon in iscsid,
but better. Or maybe submit patches to iscsid to improve/enhance the
discovery daemon. :)

SUMMARY
===
But to get back to your initial question, the major functionality of
iscsid is *not* compromised when it is retrying forever to reconnect a
stale session, though it *is* wasting resources and can have other
negative side-effects, as listed above.

-- 
The Lee-Man

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH] iscsi: fall back to sendmsg for slab pages

[Lee Duncan]

On 3/6/19 3:33 AM, Vasily Averin wrote:
> James, Martin,
> noone replied 2 weeks,
> could you please pick up this patch?
> 
> According to Network guru sendpage must not be called for Slab objects.
> Unfortunately this happen in real life, for example when XFS send metadata 
> via network block device.
> Some of such cases -- drbd and ceph -- already have PageSlab() check, however 
> iscsi still lacks it.
> 
> It was triggered host to crash during internal OpenVZ tests,
> fixed kernel passed this test successfully.
> 
> This patch forces iscsi_tcp_segment_map() to set up segment->data for Slab 
> pages
> and it switches iscsi_sw_tcp_xmit_segment() to use sendmsg instead of 
> sendpage. 
> 
> Thank you,
>   Vasily Averin
> 
> On 2/21/19 6:23 PM, Vasily Averin wrote:
>> In "XFS over network block device" scenario XFS can create IO requests
>> with slab-based XFS metadata. During processing such requests
>> tcp_sendpage() can merge skb fragments with neighbour slab objects.
>>
>> If receiving side is located on the same host tcp_recvmsg() can trigger
>> BUG_ON in hardening check and crash the host with following message:
>>
>> usercopy: kernel memory exposure attempt detected
>>  from  (kmalloc-512) (1024 bytes)
>>
>> This patch redirect such requests from sednpage to sendmsg path.
>> The problem is similar to one described in recent commit 7e241f647dc7
>> ("libceph: fall back to sendmsg for slab pages")
>>
>> Signed-off-by: Vasily Averin 
>> ---
>>  drivers/scsi/libiscsi_tcp.c | 11 ---
>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c
>> index 8a6b1b3f8277..66d97d3bef5a 100644
>> --- a/drivers/scsi/libiscsi_tcp.c
>> +++ b/drivers/scsi/libiscsi_tcp.c
>> @@ -129,12 +129,17 @@ static void iscsi_tcp_segment_map(struct iscsi_segment 
>> *segment, int recv)
>>  BUG_ON(sg->length == 0);
>>  
>>  /*
>> + * We always map for the recv path.
>> + *
>>   * If the page count is greater than one it is ok to send
>>   * to the network layer's zero copy send path. If not we
>> - * have to go the slow sendmsg path. We always map for the
>> - * recv path.
>> + * have to go the slow sendmsg path.
>> + *
>> + * Same goes for slab pages: skb_can_coalesce() allows
>> + * coalescing neighboring slab objects into a single frag which
>> + * triggers one of hardened usercopy checks.
>>   */
>> -if (page_count(sg_page(sg)) >= 1 && !recv)
>> +if (!recv && page_count(sg_page(sg)) >= 1 && !PageSlab(sg_page(sg)))
>>  return;
>>  
>>  if (recv) {
>>
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [RESEND PATCH] libiscsi: Fix race between iscsi_xmit_task and iscsi_complete_task

[Lee Duncan]

On 2/12/19 9:21 PM, Bob Liu wrote:
> From: Anoob Soman 
> 
> When a target sends Check Condition, whilst initiator is busy xmiting
> re-queued data, could lead to race between iscsi_complete_task() and
> iscsi_xmit_task() and eventually crashing with the following kernel
> backtrace.
> 
> [3326150.987523] ALERT: BUG: unable to handle kernel NULL pointer dereference 
> at 0078
> [3326150.987549] ALERT: IP: [] iscsi_xmit_task+0x2d/0xc0 
> [libiscsi]
> [3326150.987571] WARN: PGD 569c8067 PUD 569c9067 PMD 0
> [3326150.987582] WARN: Oops: 0002 [#1] SMP
> [3326150.987593] WARN: Modules linked in: tun nfsv3 nfs fscache dm_round_robin
> [3326150.987762] WARN: CPU: 2 PID: 8399 Comm: kworker/u32:1 Tainted: G O 
> 4.4.0+2 #1
> [3326150.987774] WARN: Hardware name: Dell Inc. PowerEdge R720/0W7JN5, BIOS 
> 2.5.4 01/22/2016
> [3326150.987790] WARN: Workqueue: iscsi_q_13 iscsi_xmitworker [libiscsi]
> [3326150.987799] WARN: task: 8801d50f3800 ti: 8801f5458000 task.ti: 
> 8801f5458000
> [3326150.987810] WARN: RIP: e030:[] [] 
> iscsi_xmit_task+0x2d/0xc0 [libiscsi]
> [3326150.987825] WARN: RSP: e02b:8801f545bdb0 EFLAGS: 00010246
> [3326150.987831] WARN: RAX: ffc3 RBX: 880282d2ab20 RCX: 
> 88026b6ac480
> [3326150.987842] WARN: RDX:  RSI: fe01 RDI: 
> 880282d2ab20
> [3326150.987852] WARN: RBP: 8801f545bdc8 R08:  R09: 
> 0008
> [3326150.987862] WARN: R10:  R11: fe88 R12: 
> 
> [3326150.987872] WARN: R13: 880282d2abe8 R14: 880282d2abd8 R15: 
> 880282d2ac08
> [3326150.987890] WARN: FS: 7f5a866b4840() GS:88028a64() 
> knlGS:
> [3326150.987900] WARN: CS: e033 DS:  ES:  CR0: 80050033
> [3326150.987907] WARN: CR2: 0078 CR3: 70244000 CR4: 
> 00042660
> [3326150.987918] WARN: Stack:
> [3326150.987924] WARN: 880282d2ad58 880282d2ab20 880282d2abe8 
> 8801f545be18
> [3326150.987938] WARN: a05cea90 880282d2abf8 88026b59cc80 
> 88026b59cc00
> [3326150.987951] WARN: 88022acf32c0 880289491800 880255a80800 
> 0400
> [3326150.987964] WARN: Call Trace:
> [3326150.987975] WARN: [] iscsi_xmitworker+0x2f0/0x360 
> [libiscsi]
> [3326150.987988] WARN: [] process_one_work+0x1fc/0x3b0
> [3326150.987997] WARN: [] worker_thread+0x2a5/0x470
> [3326150.988006] WARN: [] ? __schedule+0x648/0x870
> [3326150.988015] WARN: [] ? rescuer_thread+0x300/0x300
> [3326150.988023] WARN: [] kthread+0xd5/0xe0
> [3326150.988031] WARN: [] ? kthread_stop+0x110/0x110
> [3326150.988040] WARN: [] ret_from_fork+0x3f/0x70
> [3326150.988048] WARN: [] ? kthread_stop+0x110/0x110
> [3326150.988127] ALERT: RIP [] iscsi_xmit_task+0x2d/0xc0 
> [libiscsi]
> [3326150.988138] WARN: RSP 
> [3326150.988144] WARN: CR2: 0078
> [3326151.020366] WARN: ---[ end trace 1c60974d4678d81b ]---
> 
> Commit 6f8830f5bbab (scsi: libiscsi: add lock around task lists to fix list
> corruption regression) introduced "taskqueuelock" to fix list corruption 
> during
> the race, but this wasn't enough.
> 
> Re-setting of conn->task to NULL, could race with iscsi_xmit_task().
> iscsi_complete_task()


> {
> 
> if (conn->task == task)
> conn->task = NULL;
> }
> 
> conn->task in iscsi_xmit_task() could be NULL and so will be task.
> __iscsi_get_task(task) will crash (NullPtr de-ref), trying to access refcount.
> 
> iscsi_xmit_task()
> {
> struct iscsi_task *task = conn->task;
> 
> __iscsi_get_task(task);
> }
> 
> This commit will take extra conn->session->back_lock in iscsi_xmit_task()
> to ensure iscsi_xmit_task() waits for iscsi_complete_task(), if
> iscsi_complete_task() wins the race.
> If iscsi_xmit_task() wins the race, iscsi_xmit_task() increments 
> task->refcount
> (__iscsi_get_task) ensuring iscsi_complete_task() will not iscsi_free_task().
> 
> Signed-off-by: Anoob Soman 
> Signed-off-by: Bob Liu 
> ---
>  drivers/scsi/libiscsi.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index b8d325ce8754..120fc520f27a 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -1459,7 +1459,13 @@ static int iscsi_xmit_task(struct iscsi_conn *conn)
>   if (test_bit(ISCSI_SUSPEND_BIT, >suspend_tx))
>   return -ENODATA;
>  
> + spin_lock_bh(>session->back_lock);
> + if (conn->task == NULL) {
> + spin_unlock_bh(>session->back_lock);
> + return -ENODATA;
> +   

Re: [RESEND PATCH] libiscsi: Fix race between iscsi_xmit_task and iscsi_complete_task

[Lee Duncan]

On 2/12/19 9:21 PM, Bob Liu wrote:
> From: Anoob Soman 
> 
> When a target sends Check Condition, whilst initiator is busy xmiting
> re-queued data, could lead to race between iscsi_complete_task() and
> iscsi_xmit_task() and eventually crashing with the following kernel
> backtrace.
> 
> [3326150.987523] ALERT: BUG: unable to handle kernel NULL pointer dereference 
> at 0078
> [3326150.987549] ALERT: IP: [] iscsi_xmit_task+0x2d/0xc0 
> [libiscsi]
> [3326150.987571] WARN: PGD 569c8067 PUD 569c9067 PMD 0
> [3326150.987582] WARN: Oops: 0002 [#1] SMP
> [3326150.987593] WARN: Modules linked in: tun nfsv3 nfs fscache dm_round_robin
> [3326150.987762] WARN: CPU: 2 PID: 8399 Comm: kworker/u32:1 Tainted: G O 
> 4.4.0+2 #1
> [3326150.987774] WARN: Hardware name: Dell Inc. PowerEdge R720/0W7JN5, BIOS 
> 2.5.4 01/22/2016
> [3326150.987790] WARN: Workqueue: iscsi_q_13 iscsi_xmitworker [libiscsi]
> [3326150.987799] WARN: task: 8801d50f3800 ti: 8801f5458000 task.ti: 
> 8801f5458000
> [3326150.987810] WARN: RIP: e030:[] [] 
> iscsi_xmit_task+0x2d/0xc0 [libiscsi]
> [3326150.987825] WARN: RSP: e02b:8801f545bdb0 EFLAGS: 00010246
> [3326150.987831] WARN: RAX: ffc3 RBX: 880282d2ab20 RCX: 
> 88026b6ac480
> [3326150.987842] WARN: RDX:  RSI: fe01 RDI: 
> 880282d2ab20
> [3326150.987852] WARN: RBP: 8801f545bdc8 R08:  R09: 
> 0008
> [3326150.987862] WARN: R10:  R11: fe88 R12: 
> 
> [3326150.987872] WARN: R13: 880282d2abe8 R14: 880282d2abd8 R15: 
> 880282d2ac08
> [3326150.987890] WARN: FS: 7f5a866b4840() GS:88028a64() 
> knlGS:
> [3326150.987900] WARN: CS: e033 DS:  ES:  CR0: 80050033
> [3326150.987907] WARN: CR2: 0078 CR3: 70244000 CR4: 
> 00042660
> [3326150.987918] WARN: Stack:
> [3326150.987924] WARN: 880282d2ad58 880282d2ab20 880282d2abe8 
> 8801f545be18
> [3326150.987938] WARN: a05cea90 880282d2abf8 88026b59cc80 
> 88026b59cc00
> [3326150.987951] WARN: 88022acf32c0 880289491800 880255a80800 
> 0400
> [3326150.987964] WARN: Call Trace:
> [3326150.987975] WARN: [] iscsi_xmitworker+0x2f0/0x360 
> [libiscsi]
> [3326150.987988] WARN: [] process_one_work+0x1fc/0x3b0
> [3326150.987997] WARN: [] worker_thread+0x2a5/0x470
> [3326150.988006] WARN: [] ? __schedule+0x648/0x870
> [3326150.988015] WARN: [] ? rescuer_thread+0x300/0x300
> [3326150.988023] WARN: [] kthread+0xd5/0xe0
> [3326150.988031] WARN: [] ? kthread_stop+0x110/0x110
> [3326150.988040] WARN: [] ret_from_fork+0x3f/0x70
> [3326150.988048] WARN: [] ? kthread_stop+0x110/0x110
> [3326150.988127] ALERT: RIP [] iscsi_xmit_task+0x2d/0xc0 
> [libiscsi]
> [3326150.988138] WARN: RSP 
> [3326150.988144] WARN: CR2: 0078
> [3326151.020366] WARN: ---[ end trace 1c60974d4678d81b ]---
> 
> Commit 6f8830f5bbab (scsi: libiscsi: add lock around task lists to fix list
> corruption regression) introduced "taskqueuelock" to fix list corruption 
> during
> the race, but this wasn't enough.
> 
> Re-setting of conn->task to NULL, could race with iscsi_xmit_task().
> iscsi_complete_task()
> {
> 
> if (conn->task == task)
> conn->task = NULL;
> }
> 
> conn->task in iscsi_xmit_task() could be NULL and so will be task.
> __iscsi_get_task(task) will crash (NullPtr de-ref), trying to access refcount.
> 
> iscsi_xmit_task()
> {
> struct iscsi_task *task = conn->task;
> 
> __iscsi_get_task(task);
> }
> 
> This commit will take extra conn->session->back_lock in iscsi_xmit_task()
> to ensure iscsi_xmit_task() waits for iscsi_complete_task(), if
> iscsi_complete_task() wins the race.
> If iscsi_xmit_task() wins the race, iscsi_xmit_task() increments 
> task->refcount
> (__iscsi_get_task) ensuring iscsi_complete_task() will not iscsi_free_task().
> 
> Signed-off-by: Anoob Soman 
> Signed-off-by: Bob Liu 
> ---
>  drivers/scsi/libiscsi.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index b8d325ce8754..120fc520f27a 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -1459,7 +1459,13 @@ static int iscsi_xmit_task(struct iscsi_conn *conn)
>   if (test_bit(ISCSI_SUSPEND_BIT, >suspend_tx))
>   return -ENODATA;
>  
> + spin_lock_bh(>session->back_lock);
> + if (conn->task == NULL) {
> + spin_unlock_bh(>session->back_lock);
> + return -ENODATA;
> +   

Re: [PATCH] iscsi: Capture iscsi debug messages using tracepoints

[Lee Duncan]

   ),
> +
> + TP_printk("%s: %s",__get_str(dname),  __get_str(msg)
> + )
> +);
> +
> +/*
> + * Define event to capture iscsi connection debug messages.
> + */
> +DEFINE_EVENT(iscsi_log_msg, iscsi_dbg_conn,
> + TP_PROTO(struct device *dev, struct va_format *vaf),
> +
> + TP_ARGS(dev, vaf)
> +);
> +
> +/*
> + * Define event to capture iscsi session debug messages.
> + */
> +DEFINE_EVENT(iscsi_log_msg, iscsi_dbg_session,
> + TP_PROTO(struct device *dev, struct va_format *vaf),
> +
> + TP_ARGS(dev, vaf)
> +);
> +
> +/*
> + * Define event to capture iscsi error handling debug messages.
> + */
> +DEFINE_EVENT(iscsi_log_msg, iscsi_dbg_eh,
> +TP_PROTO(struct device *dev, struct va_format *vaf),
> +
> +TP_ARGS(dev, vaf)
> +);
> +
> +/*
> + * Define event to capture iscsi tcp debug messages.
> + */
> +DEFINE_EVENT(iscsi_log_msg, iscsi_dbg_tcp,
> +TP_PROTO(struct device *dev, struct va_format *vaf),
> +
> +TP_ARGS(dev, vaf)
> +);
> +
> +/*
> + * Define event to capture iscsi sw tcp debug messages.
> + */
> +DEFINE_EVENT(iscsi_log_msg, iscsi_dbg_sw_tcp,
> + TP_PROTO(struct device *dev, struct va_format *vaf),
> +
> + TP_ARGS(dev, vaf)
> +);
> +
> +/*
> + * Define event to capture iscsi transport session debug messages.
> + */
> +DEFINE_EVENT(iscsi_log_msg, iscsi_dbg_trans_session,
> + TP_PROTO(struct device *dev, struct va_format *vaf),
> +
> + TP_ARGS(dev, vaf)
> +);
> +
> +/*
> + * Define event to capture iscsi transport connection debug messages.
> + */
> +DEFINE_EVENT(iscsi_log_msg, iscsi_dbg_trans_conn,
> + TP_PROTO(struct device *dev, struct va_format *vaf),
> +
> + TP_ARGS(dev, vaf)
> +);
> +
> +#endif /* _TRACE_ISCSI_H */
> +
> +/* This part must be outside protection */
> +#include 
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH] libiscsi: Fix NULL pointer dereference in iscsi_eh_session_reset

[Lee Duncan]

On 11/20/18 5:22 PM, fred.her...@oracle.com wrote:
> From: Fred Herard 
> 
> This commit addresses NULL pointer dereference in iscsi_eh_session_reset.
> Reference should not be made to session->leadconn when session->state
> is set to ISCSI_STATE_TERMINATE.
> 
> Signed-off-by: Fred Herard 
> Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  drivers/scsi/libiscsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index 088e903..21d2a6d 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -2426,8 +2426,8 @@ int iscsi_eh_session_reset(struct scsi_cmnd *sc)
>  failed:
>   ISCSI_DBG_EH(session,
>"failing session reset: Could not log back into "
> -  "%s, %s [age %d]\n", session->targetname,
> -  conn->persistent_address, session->age);
> +  "%s [age %d]\n", session->targetname,
> +  session->age);
>       spin_unlock_bh(>frwd_lock);
>   mutex_unlock(>eh_mutex);
>   return FAILED;
> 

Reviewed-by: Lee Duncan 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Antw: Re: Initial Login Advice

[Lee Duncan]

On Nov 5, 2018, at 12:10 AM, Ulrich Windl  
wrote:
> 
> Hi!
> 
> I wonder: On Fibre-Channel (FC) SAN stroage systems, some systems indicate 
> when there are new LUNs available, while others do not. Linux clients 
> sometimes understand what the storage system is telling them, sometimes not. 
> So usually one has to rescan the scsi bus to find new (or obsolete) LUNs.
> Does the SCSI protocol have provisions to indicate a new target is available? 
> Maybe it depends on the details: I'd guess a device that is in the state of 
> becoming ready would be detected, but would have a state like "target is 
> becoming ready" (which could be polled using TUR, I guess).
> If the whole storage system is down, the situation is different, but in the 
> FC case a new target would be still signalled on the FC bus at least (via LIP 
> (loop Initialization Primitive) I think)...
> 
> Could such events trigger an iSCSI login?
> 
> Regards,
> Ulrich

Fibre Channel has asynchronous notification built into its protocol (as does 
InfiniBand), since those standards were created *after* SCSI was well 
established.

There is a thing called AN (asynchronous notification), but it’s thinly 
supported and not available at all for storage systems.

Yes, of course a client can poll a storage box, but iSCSI in general does not 
do this, as part of its protocol.

The best solution for iSCSI, IMHO, is ISNS. That is what iSNS was designed for. 
If you’re using targetcli-fb as your iSCSI target, it supports iSNS, as does 
open-iscsi.

Part of the reason for this lack of support is that SCSI was designed for 
static discs, i.e. it was not expected that discs would be coming and going all 
the time. A disc is just supposed to be there, all the time (like dial tone). 
So the SCSI protocol assumed that was the case.

If you want truly asynchronous storage, but a commercial FC storage box (IMHO). 
If you want asynchronous iSCSI, use iSNS (see open-isns, a project I maintain 
on github).
— 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: New open-iscsi minor version?

[Lee Duncan]

Sorry, this “changed” list seems to be doubled! :O

There were about 100 commits, about 40 of which are merge commits.

> On Oct 16, 2018, at 2:07 PM, The Lee-Man  wrote:
> 
> I'm planning on updating the open-iscsi version to 2.0.877 "real soon now", 
> unless I hear any objections.
> 
> Here's a list of what's changed:
> 
> Antoine de Maleprade (1):
>   iscsid: fix logging level when starting daemon
> 
> Cathy Zhou (1):
>   Reduce delays to improve iscsi boot performance
> 
> Chris Leech (16):
>   libopeniscsiusr: fixes err on prefix_len
>   vlan setting sync across ipv4/ipv6 for be2iscsi
>   iscsid logging blank messages at level EMERG
>   iscsistart: prevent unix socket cross-talk
>   libopeniscsiusr: hosts can have multiple ifaces
>   libopeniscsiusr: clear errno before calling strtoll
>   libopeniscsiusr: setup ipv6 records based on iface name
>   libopeniscsiusr: use asprintf and remove PATH_MAX stack buffers
>   Merge pull request #110 from cleech/libopeniscsiusr_fixes
>   Merge pull request #111 from cleech/for_upstream
>   Merge pull request #106 from phmccarty/lib-symlinks
>   enable MaxOutstandingR2T negotiation
>   Merge pull request #114 from njavali/iscsiuio-bug-fixes
>   Merge pull request #115 from cleech/for_upstream
>   Merge pull request #120 from maxnet/va
>   Merge pull request #122 from njavali/iscsiuio-bug-fixes
> 
> Christian Ehrhardt (2):
>   iscsiuio: avoid loosing bad rc in nic_nl_open
>   iscsiuio: fail on nic_nl_open failing
> 
> Floris Bos (1):
>   context.h: add missing stdarg.h include
> 
> Gris Ge (8):
>   libopeniscsiusr: Fix iscsi_sessions_free() on 0 se_count.
>   libopeniscsiusr: Add full iscsi interface support.
>   Makefile: Trivial change on aligning output.
>   libopeniscsiusr: Fix incorrect debug message for iface query.
>   libopeniscsiusr: Add node query support
>   libopeniscsiusr: Fix iscsi_iface_get() on default interfaces.
>   iscsiadm: Use libopeniscsiusr in `iscsiadm -m iface -P1`
>   libopeniscsiusr: Fix compile error on GCC 8.
> 
> Khem Raj (6):
>   libopeniscsiusr: Include limit.h for PATH_MAX
>   libopeniscsiusr: Add CFLAGS to linker cmdline
>   qedi.c: Removed unused linux/ethtool.h
>   idbm.c: Include fcnl.h for O_RDWR and O_CREAT definitions
>   bnx2x.c: Reorder the includes to avoid duplicate defines with musl
>   fwparam_ppc.c: Do not use __compar_fn_t
> 
> Lee Duncan (55):
>   Merge pull request #91 from njavali/iscsiuio-bug-fixes
>   Merge pull request #92 from az0uz/master
>   Use correct size when copying nic name.
>   Do not overload global sysfs_path locally.
>   libopeniscsiusr: ensure sysfs pathname doesn't overflow.
>   Ensure sysfs pathname doesn't overflow.
>   Merge pull request #89 from kraj/kraj/musl-fixes
>   Merge pull request #94 from gonzoleeman/gcc-8-fixes
>   Merge branch 'master' into api
>   Merge pull request #93 from cathay4t/api
>   Keep iscsi_if in sync with kernel version.
>   Add a TODO item on iscsi_if.h.
>   Merge pull request #98 from gonzoleeman/update-iscsi_if-to-latest
>   Add error message for new ISCSI_ERR_NOP_TIMEDOUT
>   Merge pull request #99 from gonzoleeman/handle-new-kernel-error-code
>   Allow a host_id value of zero.
>   Merge pull request #100 from 
> gonzoleeman/libopeniscsiusr-allow-zero-host_id
>   Merge pull request #101 from gonzoleeman/fix-qedi-iface-name
>   Fix iscsiuio segfault when shutting down.
>   Remove unused file fwparam_ibft_sysfs.c.
>   Merge pull request #96 from cathay4t/api
>   Merge pull request #103 from cathy-zhou/perf_fix
>   Plugging a memory leak from discovery.
>   Merge pull request #123 from gonzoleeman/fix-discovery-leak
>   Allow reading sysfs "port" to fail gracefully.
>   Fix incorrect sysfs logic for port and ip address.
>   Fix reading of sysfs signed integers when negative.
>   Create a new error for "target not connected".
>   Fix bug in error message when reading sysfs numbers.
>   Handle ENOTCONN error separately when reading sysfs values.
>   Limit session relogin attempts using config value.
>   Merge pull request #127 from smoser/fix/iscsid-pidfile-write
>   Merge pull request #129 from cpaelzer/cleanup-nic_nl_open-usage
>   Merge pull request #131 from gonzoleeman/fix-reconnect-forever
>   Removed unused value 'one'.
>   Include stdio.h for use of snprintf().
>   Fix qsort() comparator function call.
>   Merge pull request #132 from gonzoleeman/small-c

RFC: A problem with stale session information?

[Lee Duncan]

Hi All:

I have been tracking down an issue that has to do with iSCSI sessions going 
away.

If an initiator and target have a session, then iscsid goes away (stops or 
dies, without logging out of the session), and then the target goes away, 
iscsid has an issue when it starts back up.

It looks like iscsid retries forever to reconnect the session. There doesn’t 
appear to be any code that gives up and cleans up the session. Ever.

During this retry-forever period, any attempt to access important session 
information from sysfs returns ENOTCONN — a pretty clear indication that the 
node is not connected.

It seems to me like this is a bug. Or two:

1 - The retries should be limited to something reasonable, then give up and 
clean up the session, assuming it’s “bad”, and

2 - When iscsiadm sees the ENOTCONN, it should print out a message saying “in 
recovery to unconnected node, try again” while the retries are going on.

Another approach might be to let the retries go on forever, or until a user 
runs some sort of “force the session to end” command?

I have been looking at this a while, and it’s not clear how simple it will be 
to implement either of these approaches. Right now, this registers as a 
“libopeniscsiusr BUG”, which is not acceptable.

Ideas? We need some way (besides reboot) to say “this target is never coming 
back”, right?

— 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH] scsi: iscsi_tcp: set BDI_CAP_STABLE_WRITES when data digest enabled

[Lee Duncan]

I reviewed this several days before but mistakenly replied only to the 
open-iscsi list. 

Signed-off-by: Lee Duncan <ldun...@suse.com>

--
Lee-Man Duncan
Sent from my iPhone, dude


> On Mar 14, 2018, at 10:11 PM, Martin K. Petersen <martin.peter...@oracle.com> 
> wrote:
> 
> 
>> iscsi tcp will first send out data, then calculate and send data
>> digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will
>> be written in spite of the on going writeback. Consequently, wrong
>> digest will be got and sent to target.
>> 
>> To fix this, set BDI_CAP_STABLE_WRITES when data digest is enabled
>> in iscsi_tcp .slave_configure callback.
> 
> Lee, Chris: Please review!
> 
> -- 
> Martin K. PetersenOracle Linux Engineering
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "open-iscsi" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/open-iscsi/owLIZAXfgoA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> open-iscsi+unsubscr...@googlegroups.com.
> To post to this group, send email to open-iscsi@googlegroups.com.
> Visit this group at https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 2/2] libiscsi: Annotate fall-through

[Lee Duncan]

On 03/01/2018 10:07 AM, Bart Van Assche wrote:
> This patch avoids that building with W=1 causes the compiler to
> complain about fall-through.
> 
> Signed-off-by: Bart Van Assche <bart.vanass...@wdc.com>
> Cc: Lee Duncan <ldun...@suse.com>
> Cc: Chris Leech <cle...@redhat.com>
> ---
>  drivers/scsi/libiscsi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index b39bfdfec337..345533f80dae 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -1705,6 +1705,7 @@ int iscsi_queuecommand(struct Scsi_Host *host, struct 
> scsi_cmnd *sc)
>   sc->result = DID_NO_CONNECT << 16;
>   break;
>   }
> + /* fall through */
>   case ISCSI_STATE_IN_RECOVERY:
>   reason = FAILURE_SESSION_IN_RECOVERY;
>       sc->result = DID_IMM_RETRY << 16;
> 
Signed-off-by: Lee Duncan <ldun...@suse.com>
-- 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH] scsi: libiscsi: Allow sd_shutdown on bad transport

[Lee Duncan]

On 12/07/2017 01:59 PM, Rafael David Tinoco wrote:
> If, for any reason, userland shuts down iscsi transport interfaces
> before proper logouts - like when logging in to LUNs manually,
> without logging out on server shutdown, or when automated scripts
> can't umount/logout from logged LUNs - kernel will hang forever on
> its sd_sync_cache() logic, after issuing the SYNCHRONIZE_CACHE cmd
> to all still existent paths.
> 
> PID: 1 TASK: 8801a69b8000 CPU: 1 COMMAND: "systemd-shutdow"
>  #0 [8801a69c3a30] __schedule at 8183e9ee
>  #1 [8801a69c3a80] schedule at 8183f0d5
>  #2 [8801a69c3a98] schedule_timeout at 81842199
>  #3 [8801a69c3b40] io_schedule_timeout at 8183e604
>  #4 [8801a69c3b70] wait_for_completion_io_timeout at 8183fc6c
>  #5 [8801a69c3bd0] blk_execute_rq at 813cfe10
>  #6 [8801a69c3c88] scsi_execute at 815c3fc7
>  #7 [8801a69c3cc8] scsi_execute_req_flags at 815c60fe
>  #8 [8801a69c3d30] sd_sync_cache at 815d37d7
>  #9 [8801a69c3da8] sd_shutdown at 815d3c3c
> 
> This happens because iscsi_eh_cmd_timed_out(), the transport layer
> timeout helper, would tell the queue timeout function (scsi_times_out)
> to reset the request timer over and over, until the session state is
> back to logged in state. Unfortunately, during server shutdown, this
> might never happen again.
> 
> Other option would be "not to handle" the issue in the transport
> layer. That would trigger the error handler logic, which would also
> need the session state to be logged in again.
> 
> Best option, for such case, is to tell upper layers that the command
> was handled during the transport layer error handler helper, marking
> it as DID_NO_CONNECT, which will allow completion and inform about
> the problem.
> 
> After the session was marked as ISCSI_STATE_FAILED, due to the first
> timeout during the server shutdown phase, all subsequent cmds will
> fail to be queued, allowing upper logic to fail faster.
> 
> Signed-off-by: Rafael David Tinoco <rafael.tin...@canonical.com>
> ---
>  drivers/scsi/libiscsi.c | 24 +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index 9c50d2d9f27c..785d1c55d152 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -1696,6 +1696,15 @@ int iscsi_queuecommand(struct Scsi_Host *host, struct 
> scsi_cmnd *sc)
>*/
>   switch (session->state) {
>   case ISCSI_STATE_FAILED:
> + /*
> +  * cmds should fail during shutdown, if the session
> +  * state is bad, allowing completion to happen
> +  */
> + if (unlikely(system_state != SYSTEM_RUNNING)) {
> + reason = FAILURE_SESSION_FAILED;
> + sc->result = DID_NO_CONNECT << 16;
> + break;
> + }
>   case ISCSI_STATE_IN_RECOVERY:
>   reason = FAILURE_SESSION_IN_RECOVERY;
>   sc->result = DID_IMM_RETRY << 16;
> @@ -1978,6 +1987,19 @@ enum blk_eh_timer_return iscsi_eh_cmd_timed_out(struct 
> scsi_cmnd *sc)
>   }
>  
>   if (session->state != ISCSI_STATE_LOGGED_IN) {
> + /*
> +  * During shutdown, if session is prematurely disconnected,
> +  * recovery won't happen and there will be hung cmds. Not
> +  * handling cmds would trigger EH, also bad in this case.
> +  * Instead, handle cmd, allow completion to happen and let
> +  * upper layer to deal with the result.
> +  */
> + if (unlikely(system_state != SYSTEM_RUNNING)) {
> + sc->result = DID_NO_CONNECT << 16;
> + ISCSI_DBG_EH(session, "sc on shutdown, handled\n");
> + rc = BLK_EH_HANDLED;
> + goto done;
> + }
>   /*
>* We are probably in the middle of iscsi recovery so let
>* that complete and handle the error.
> @@ -2082,7 +2104,7 @@ enum blk_eh_timer_return iscsi_eh_cmd_timed_out(struct 
> scsi_cmnd *sc)
>       task->last_timeout = jiffies;
>   spin_unlock(>frwd_lock);
>   ISCSI_DBG_EH(session, "return %s\n", rc == BLK_EH_RESET_TIMER ?
> -  "timer reset" : "nh");
> +  "timer reset" : "shutdown or nh"

Re: backstores/iblock missing

[Lee Duncan]

> On Dec 25, 2017, at 11:35 AM, melek ozel <melekozel2...@gmail.com> wrote:
> 
> I preassume there are several tools for both initiator and target.IBLOCK is 
> just a storage object on target just like "backstores/block".I came across 
> that on one of wikipage.I am looking for some wikipage or tutorial which 
> throw this dust away.I came across few tutorials which explain 
> target/initiator setup with openiscsi.this is how I ended up over here. what 
> is the difference between using this "iscsi-initiator-utils" and openiscsi if 
> there is already target configured?

The name “iscsi-initiator-utils” is a name for a package that contains the 
open-iscsi initiator software.

The open-iscsi iSCSI initiator software allows a system to connect to iSCSI 
targets, making them look like local discs, once connected. It also facilitates 
discovering such targets. There really aren’t any other Linux OSS initiators I 
know about.

There are several Linux iSCSI target packages, but the “good” one these days is 
targetcli-fb. The “fb” stands for the “free branch” of targetcli. Read there 
web page if you want more info about the history. :)

The targetcli-fb package supplies the targetcli command. This command allows 
you to set up targets that open-iscsi can connect to.

There is no “iblock” format in targetcli. You can use backstores/block to have 
targetcli use a block device for your iSCSI target backing store. Or you can 
use a file with backstores/fileio. The README.md that comes with targetcli-fb 
has a pretty good bare-bones tutorial on setting up each.

> 
> On Fri, Dec 22, 2017 at 4:13 AM, The Lee-Man <leeman.dun...@gmail.com 
> <mailto:leeman.dun...@gmail.com>> wrote:
> On Thursday, December 21, 2017 at 12:10:52 AM UTC-8, malteseLun wrote:
> Is there a list that I can see CLIs for scsi targets? actually I cant find 
> openiscsi on centos 7.4. couldnot even install with yum. I am trying to 
> implement "IBLOCK(any block device).I cant see IBLOCK on targetcli and saw 
> some posts openiscsi listing IBLOCK, few howtos actually.
> 
> 
> Perhaps you're getting iSCSi initiators confused with iSCSI targets? The 
> open-iscsi project supplies an open-source iSCSI initiator. The targetcli-fb 
> project (and the older targetcli project which it replaces) are an 
> open-source iSCSI target.
> 
> I don't know what "CLIs for scsi targets" is. Perhaps you mean the targetcli 
> command, which lists all iSCSI targets (among other things).
> 
> You shouldn't need open-iscsi if all you want to do is supply iSCSI targets. 
> But if you want to be able to connect to those (or any) iSCSI targets with an 
> initiator, then open-iscsi is useful for that.
> 
> I don't know what "IBLOCK" is. I know that it is possible to share a zfs 
> volume using targetcli, if that is your goal.
> 

-- 
Lee Duncan

"A witty saying proves nothing." -- Voltaire



-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC dracut 1/1] unexpected boot failure due to races between iscsistart for multiple interfaces

[Lee Duncan]

Hi Cathy:

Too many quote levels, so I’m starting from scratch.

I understand now that what you are talking about is your dracut environment, 
not run time iscsi initiator support.

In this environment, how is iscsid getting started?

As you know, the change you propose is a dracut change, not an open-iscsi 
change. Never the less, I’d like to reply to your request for comment.

I think the key is in this, from your first RFC email:

>Therefore, to fix the issue, we'd either choose to remove the
>use of
>iscsid and solely use iscsistart or to remove iscsistart and
>use iscsid
>and iscsiadm to manage the iSCSI sessions.

That seems like the wrong approach to me. iscsiadm/iscsid were designed for 
this. The iscsistart script was designed for sing, one-shot use, and is not 
used in dracut now at all, AFAIK.

— 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [RFC dracut 1/1] unexpected boot failure due to races between iscsistart for multiple interfaces

[Lee Duncan]

-  $systemdsystemunitdir/iscsid.socket \
>>-  $systemdsystemunitdir/iscsiuio.service \
>>-  $systemdsystemunitdir/iscsiuio.socket \
>>-  iscsiadm iscsid
>>-
>>-mkdir -p
>>"${initdir}/$systemdsystemunitdir/sockets.target.wants"
>>-for i in \
>>-iscsiuio.socket \
>>-; do
>>-ln_r "$systemdsystemunitdir/${i}"
>>"$systemdsystemunitdir/sockets.target.wants/${i}"
>>-done
>>-
>>-mkdir -p
>>"${initdir}/$systemdsystemunitdir/basic.target.wants"
>>-for i in \
>>-iscsid.service \
>>-; do
>>-ln_r "$systemdsystemunitdir/${i}"
>>"$systemdsystemunitdir/basic.target.wants/${i}"
>>-done
>>-
>>-# Make sure iscsid is started after dracut-cmdline
>>and ready for the initqueue
>>-mkdir -p
>>"${initdir}/$systemdsystemunitdir/iscsid.service.d"
>>-(
>>-echo "[Unit]"
>>-echo "After=dracut-cmdline.service"
>>-echo "Before=dracut-initqueue.service"
>>-) >
>>"${initdir}/$systemdsystemunitdir/iscsid.service.d/dracut.conf"
>> 
>> 
>>I'm not sure why you've removed all of this.
>> 
> Because the above is added for the iscsid service, which is no longer needed.
>> 
>> 
>> fi
>> inst_dir /var/lib/iscsi
>> dracut_need_initqueue
>>diff --git a/modules.d/95iscsi/parse-iscsiroot.sh
>>b/modules.d/95iscsi/parse-iscsiroot.sh
>>index 43b2e088..c8c66ccf 100755
>>--- a/modules.d/95iscsi/parse-iscsiroot.sh
>>+++ b/modules.d/95iscsi/parse-iscsiroot.sh
>>@@ -116,11 +116,6 @@ if arg=$(getarg rd.iscsi.initiator -d
>>iscsi_initiator=) && [ -n "$arg" ] && ! [
>> if ! [ -e /etc/iscsi/initiatorname.iscsi ]; then
>> mkdir -p /etc/iscsi
>> ln -fs /run/initiatorname.iscsi
>>/etc/iscsi/initiatorname.iscsi
>>-if [ -n "$DRACUT_SYSTEMD" ]; then
>>-systemctl try-restart iscsid
>>-# FIXME: iscsid is not yet ready, when the
>>service is :-/
>>-sleep 1
>>-fi
>> fi
>> fi
>> 
>>@@ -133,11 +128,6 @@ if [ -z $iscsi_initiator ] && [ -f
>>/sys/firmware/ibft/initiator/initiator-name ]
>> mkdir -p /etc/iscsi
>> ln -fs /run/initiatorname.iscsi
>>/etc/iscsi/initiatorname.iscsi
>> > /tmp/iscsi_set_initiator
>>-if [ -n "$DRACUT_SYSTEMD" ]; then
>>-systemctl try-restart iscsid
>>-# FIXME: iscsid is not yet ready, when the
>>service is :-/
>>-sleep 1
>>-fi
>> fi
>> fi
>> 
>>-- 2.11.1
>> 
>>So in general you've stopped starting or restarting the iscsid
>>service?
>> 
> Yes. Actually we do not even start the iscsid service from the beginning. The 
> whole fix is to remove iscsid but only run iscsistart.

Okay, I’m glad you made this clear, because this is the problem with your 
approach.

The iscsistart program is not sufficient for supporting an iSCSI initiator. 
Namely, it does not manage sessions, so it can’t do any error handling (i.e. 
log out, log back in).

The whole reason the iscsistart program was created was that, at iSCSI boot 
time, we needed a lighter-weight program than the iscsiadm/iscsid pair to 
connect to a single target.

>> 
>> 
>>Have you tested this with iscsiuio/brcm? I have no way currently
>>to test to make sure things all still work.
>> 
> We will, and also planning to add more test cases to get more iscsiboot 
> coverage. But because this is a significant change, we'd like to get some 
> comments to say this is the right approach.
>> 
>> 
>>Note: dracut is *not* my specialty, but I have looked at this
>>stuff in the SUSE distribution, and it seems like a bit of a house
>>of cards. :(
>> 
> 
> I agree. dracut is not my specialty either.
> 
> Thank you very much!
> - Cathy
> 

Bottom line, I need to better understand why you are using iscsitart in the 
first place, if you are not booting from an iSCSI disc. And if you are using 
iscsistart, why are you running iscsid before iscsistart is done?

-- 
Lee Duncan

"Ambition is the last refuge of failure." -- Oscar Wilde


-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [Patch v2 2/2] libiscsi: Remove iscsi_destroy_session

[Lee Duncan]

On 07/13/2017 09:11 AM, Khazhismel Kumykov wrote:
> iscsi_session_teardown was the only user of this function. Function
> currently is just short for iscsi_remove_session + iscsi_free_session.
> 
> Signed-off-by: Khazhismel Kumykov <kha...@google.com>

Why is this needed? I dislike changes that don't fix anything.

> ---
>  drivers/scsi/scsi_transport_iscsi.c | 16 
>  include/scsi/scsi_transport_iscsi.h |  1 -
>  2 files changed, 17 deletions(-)
> 
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> index a424eaeafeb0..924ac408d8a9 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -2210,22 +2210,6 @@ void iscsi_free_session(struct iscsi_cls_session 
> *session)
>  }
>  EXPORT_SYMBOL_GPL(iscsi_free_session);
>  
> -/**
> - * iscsi_destroy_session - destroy iscsi session
> - * @session: iscsi_session
> - *
> - * Can be called by a LLD or iscsi_transport. There must not be
> - * any running connections.
> - */
> -int iscsi_destroy_session(struct iscsi_cls_session *session)
> -{
> - iscsi_remove_session(session);
> - ISCSI_DBG_TRANS_SESSION(session, "Completing session destruction\n");
> - iscsi_free_session(session);
> - return 0;
> -}
> -EXPORT_SYMBOL_GPL(iscsi_destroy_session);
> -
>  /**
>   * iscsi_create_conn - create iscsi class connection
>   * @session: iscsi cls session
> diff --git a/include/scsi/scsi_transport_iscsi.h 
> b/include/scsi/scsi_transport_iscsi.h
> index 6183d20a01fb..b266d2a3bcb1 100644
> --- a/include/scsi/scsi_transport_iscsi.h
> +++ b/include/scsi/scsi_transport_iscsi.h
> @@ -434,7 +434,6 @@ extern struct iscsi_cls_session 
> *iscsi_create_session(struct Scsi_Host *shost,
>   unsigned int target_id);
>  extern void iscsi_remove_session(struct iscsi_cls_session *session);
>  extern void iscsi_free_session(struct iscsi_cls_session *session);
> -extern int iscsi_destroy_session(struct iscsi_cls_session *session);
>  extern struct iscsi_cls_conn *iscsi_create_conn(struct iscsi_cls_session 
> *sess,
>   int dd_size, uint32_t cid);
>  extern int iscsi_destroy_conn(struct iscsi_cls_conn *conn);
> 

-- 
Lee Duncan
SUSE Labs

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: New version for open-iscsi?

[Lee Duncan]

On Sep 1, 2017, at 9:37 AM, Chris Leech  wrote:
> 
> On Thu, Aug 31, 2017 at 10:41:30AM -0700, The Lee-Man wrote:
>> I would like to update the version of open-iscsi from 2.0.874 to 2.0.875.
>> 
>> Any objections or suggestions?
> 
> Sounds good to me.
> 
> I'd like to do some source tree cleanups after this version update, like
> ditch the old kernel code.
> 
> Chris
> 

Sounds like a great idea.

We also need to decide what to do on the RFC for an open-iscsi library.

— 
Lee


-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

[Lee Duncan]

On 06/16/2017 05:41 PM, Jason A. Donenfeld wrote:
> Hi Lee,
> 
> On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan <ldun...@suse.com> wrote:
>> It seems like what you are doing is basically "good", i.e. if there is
>> not enough random data, don't use it. But what happens in that case? The
>> authentication fails? How does the user know to wait and try again?
> 
> The process just remains in interruptible (kill-able) sleep until
> there is enough entropy, so the process doesn't need to do anything.
> If the waiting is interrupted by a signal, it returns -ESYSRESTART,
> which follows the usual semantics of restartable syscalls.
> 
> Jason
> 

In your testing, how long might a process have to wait? Are we talking
seconds? Longer? What about timeouts?

Sorry, but your changing something that isn't exactly broken, so I just
want to be sure we're not introducing some regression, like clients
can't connect the first 5 minutes are a reboot.
-- 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

[Lee Duncan]

On 06/08/2017 05:09 AM, Jason A. Donenfeld wrote:
> On Thu, Jun 8, 2017 at 4:43 AM, Theodore Ts'o <ty...@mit.edu> wrote:
>> What was the testing that was done for commit?  It looks safe, but I'm
>> unfamiliar enough with how the iSCSI authentication works that I'd
>> prefer getting an ack'ed by from the iSCSI maintainers or
>> alternativel, information about how to kick off some kind of automated
>> test suite ala xfstests for file systems.
> 
> Only very basic testing from my end.
> 
> I'm thus adding the iSCSI list to see if they'll have a look (patch 
> reattached).
> 
> Jason
> 

It seems like what you are doing is basically "good", i.e. if there is
not enough random data, don't use it. But what happens in that case? The
authentication fails? How does the user know to wait and try again?
-- 
Lee Duncan
SUSE Labs

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[Lee Duncan]

> On Dec 28, 2016, at 4:48 AM, David C. Partridge 
>  wrote:
> 
> FWIW I still think the best solution is to suspend the NOP-Out polling (of 
> active) while a device command is being processed.  This way you get the best 
> of both worlds
>  
> However I do see the attraction of a documentation only fix J

LOL. It’s not (just) that I’m lazy. I honestly don’t think the code should 
change for this issue.

IMHO the NOP usage is a bad idea anyway, but it can be handy to detect a bad 
connection when no I/O is occurring.

The problem I think in this case is that open-iscsi does not treat tape and 
disc drives separately.

So if I send a command to a disc drive and don’t hear back for 8 minutes, I 
know that is not good. And for a disc drive, they always handle commands 
disconnected, i.e. the response for a read or write comes later, not when I 
request it. In that case, the disc brains does actually respond to PINGs while 
an operation is going on.

If we tried to add code that said “if any commands are outstanding don’t send 
PINGs”, then we could not catch the case where the disc server has gone away 
while a command was outstanding.

So unless you can come up with an idea that addresses this tape issue and 
regular usage, I don’t see any way to easily fix this.

But I’m open to suggestions. :)

>  
> Cheers
> Dave
>  
> From: open-iscsi@googlegroups.com  
> [mailto:open-iscsi@googlegroups.com ] On 
> Behalf Of The Lee-Man
> Sent: 22 December 2016 16:51
> To: open-iscsi
> Subject: Re: Problem with iSCSI connected LTO-2 tape drive
>  
> Hi David:
> 
> I have created Issue#35 for this on github.
> 
> On Thursday, December 15, 2016 at 2:00:15 PM UTC-8, David C. Partridge wrote:
> You’re right, it is in section 8.2.  Maybe it needs to be said in 8.1.1 as 
> well?
>  
> Dave
>  

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 5/8] linux: drop __bitwise__ everywhere

[Lee Duncan]

 +154,8 @@ typedef u64 dma_addr_t;
>  typedef u32 dma_addr_t;
>  #endif
>  
> -typedef unsigned __bitwise__ gfp_t;
> -typedef unsigned __bitwise__ fmode_t;
> +typedef unsigned __bitwise gfp_t;
> +typedef unsigned __bitwise fmode_t;
>  
>  #ifdef CONFIG_PHYS_ADDR_T_64BIT
>  typedef u64 phys_addr_t;
> diff --git a/include/scsi/iscsi_proto.h b/include/scsi/iscsi_proto.h
> index c1260d8..df156f1 100644
> --- a/include/scsi/iscsi_proto.h
> +++ b/include/scsi/iscsi_proto.h
> @@ -74,7 +74,7 @@ static inline int iscsi_sna_gte(u32 n1, u32 n2)
>  #define zero_data(p) {p[0]=0;p[1]=0;p[2]=0;}
>  
>  /* initiator tags; opaque for target */
> -typedef uint32_t __bitwise__ itt_t;
> +typedef uint32_t __bitwise itt_t;
>  /* below makes sense only for initiator that created this tag */
>  #define build_itt(itt, age) ((__force itt_t)\
>   ((itt) | ((age) << ISCSI_AGE_SHIFT)))
> diff --git a/include/target/target_core_base.h 
> b/include/target/target_core_base.h
> index c211900..0055828 100644
> --- a/include/target/target_core_base.h
> +++ b/include/target/target_core_base.h
> @@ -149,7 +149,7 @@ enum se_cmd_flags_table {
>   * Used by transport_send_check_condition_and_sense()
>   * to signal which ASC/ASCQ sense payload should be built.
>   */
> -typedef unsigned __bitwise__ sense_reason_t;
> +typedef unsigned __bitwise sense_reason_t;
>  
>  enum tcm_sense_reason_table {
>  #define R(x) (__force sense_reason_t )(x)
> diff --git a/include/uapi/linux/virtio_types.h 
> b/include/uapi/linux/virtio_types.h
> index e845e8c..55c3b73 100644
> --- a/include/uapi/linux/virtio_types.h
> +++ b/include/uapi/linux/virtio_types.h
> @@ -39,8 +39,8 @@
>   * - __le{16,32,64} for standard-compliant virtio devices
>   */
>  
> -typedef __u16 __bitwise__ __virtio16;
> -typedef __u32 __bitwise__ __virtio32;
> -typedef __u64 __bitwise__ __virtio64;
> +typedef __u16 __bitwise __virtio16;
> +typedef __u32 __bitwise __virtio32;
> +typedef __u64 __bitwise __virtio64;
>  
>  #endif /* _UAPI_LINUX_VIRTIO_TYPES_H */
> diff --git a/net/ieee802154/6lowpan/6lowpan_i.h 
> b/net/ieee802154/6lowpan/6lowpan_i.h
> index 5ac7789..ac7c96b 100644
> --- a/net/ieee802154/6lowpan/6lowpan_i.h
> +++ b/net/ieee802154/6lowpan/6lowpan_i.h
> @@ -7,7 +7,7 @@
>  #include 
>  #include 
>  
> -typedef unsigned __bitwise__ lowpan_rx_result;
> +typedef unsigned __bitwise lowpan_rx_result;
>  #define RX_CONTINUE  ((__force lowpan_rx_result) 0u)
>  #define RX_DROP_UNUSABLE ((__force lowpan_rx_result) 1u)
>  #define RX_DROP  ((__force lowpan_rx_result) 2u)
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index d37a577..b2069fb 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -159,7 +159,7 @@ enum ieee80211_bss_valid_data_flags {
>   IEEE80211_BSS_VALID_ERP = BIT(3)
>  };
>  
> -typedef unsigned __bitwise__ ieee80211_tx_result;
> +typedef unsigned __bitwise ieee80211_tx_result;
>  #define TX_CONTINUE  ((__force ieee80211_tx_result) 0u)
>  #define TX_DROP  ((__force ieee80211_tx_result) 1u)
>  #define TX_QUEUED((__force ieee80211_tx_result) 2u)
> @@ -180,7 +180,7 @@ struct ieee80211_tx_data {
>  };
>  
>  
> -typedef unsigned __bitwise__ ieee80211_rx_result;
> +typedef unsigned __bitwise ieee80211_rx_result;
>  #define RX_CONTINUE  ((__force ieee80211_rx_result) 0u)
>  #define RX_DROP_UNUSABLE ((__force ieee80211_rx_result) 1u)
>  #define RX_DROP_MONITOR  ((__force ieee80211_rx_result) 2u)
>

For iscsi initiator, looks good.

Akced-by: Lee Duncan <ldun...@suse.com>

-- 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[Lee Duncan]

On Dec 12, 2016, at 5:46 AM, Dave partridge <minus273ch...@gmail.com> wrote:
> 
> I just ran a Wireshark capture on the target system of the iSCSI session for 
> a Windows initiator connecting the tape and then issuing an FSF.  I then did 
> the same for the Ubuntu open-iscsi initiator.
> 
> The capture for the WIndows initiator looks pretty much as I would expect 
> (given my limited knowledge of the iSCSI protocols).
> 
> The Ubuntu/open-iscsi capture has all sorts of odd stuff like logins being 
> sent to the target every 15 seconds whle the FSF is being processed.  
> Definitely borked I think.
> 
> Do any of the open-iscsi folk watch this forum or am I talking to myself?
> 
> Dave

Hi Dave:

I think you are right — the problem is the timeout.

The default timeout on many systems (like SUSE that I work on) is set to 60 
seconds for a SCSI command. And it looks like the tape drive took about 82 
seconds to skip forward a file on your Windows trace.

Try setting the timeout to 90 seconds? The open-iscsi README talks about how to 
manually set the system SCSI timeout to longer (since this isn’t an iSCSI 
thing).

Also, you may want to disable the Ping/NOOPs that open-iscsi is setting. This 
is also discussed in the README file. I’d try setting them both to 0 to get 
them out of the way. It looks like the tape drive does not respond to the NOOP 
ping when it is busy for 80+ seconds skipping forward one file.

— 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCHv4 0/2] Handle iscsid shutdown more cleanly

[Lee Duncan]

No comment on these? Since the previous version drew comments, can I assume 
that means everybody is happy with this version?

Hannes? Anyone?


> On Nov 23, 2016, at 2:58 PM, leeman.dun...@gmail.com wrote:
> 
> From: Lee Duncan <ldun...@suse.com>
> 
> This set of two patches addresses the issues
> I mentioned on the mailing list recently relating
> to how systemd can interfere with shutting down
> the iscsid daemon. The iscsiadm command "-k"
> can hang if the daemon is not present, when
> running under systemd, when socket activated.
> 
> The first patch, from Hannes, modifies the IPC
> communications so that user-level commands, like
> iscsiadm and iscsistart, do not hang when waiting
> for a response from the iscsid daemon by using
> the poll() system call. This version also has a
> couple of small bug fixes on top of the version
> that Hannes posted recently.
> 
> The second patch modifies iscsid to treat a
> SIGTERM just like it had received the "immediate
> stop" command from iscsiadm (via the "-k"
> option), simplifying the shutdown of iscsid so
> that it no longer requires IPC communications.
> 
> Changes since v3:
> * reworked the second patch to just set the
>   "exit the polling loop" flag
> 
> Changes since v2:
> * updated first patch to rework poll() logic
> 
> Changes since v1:
> * added 2nd patch
> * fixed 2 spots in the first patch
> 
> Hannes Reinecke (1):
>  Use timeout when waiting for responses from iscsid
> 
> Lee Duncan (1):
>  iscsid: treat SIGTERM like "iscsiadm -k 0"
> 
> usr/config.h   |  1 +
> usr/discovery.c| 16 
> usr/host.c |  2 +-
> usr/iscsi_sysfs.c  |  1 +
> usr/iscsiadm.c | 12 +++-
> usr/iscsid.c   |  5 ++---
> usr/iscsid_req.c   | 51 +--
> usr/iscsid_req.h   | 15 +--
> usr/iscsistart.c   |  4 ++--
> usr/session_info.c | 14 --
> usr/session_info.h |  5 +++--
> 11 files changed, 83 insertions(+), 43 deletions(-)
> 
> -- 
> 2.1.4
> 



--
Ignore the Lee-Man behind the curtain ...

"Life's a long song. But the tune ends too soon for us all." -- Ian Anderson

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Antw: [PATCHv2 0/2] Handle iscsid shutdown more cleanly

[Lee Duncan]

On Nov 23, 2016, at 12:39 AM, Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> 
wrote:
> 
>>>> <leeman.dun...@gmail.com> schrieb am 22.11.2016 um 23:42 in Nachricht
> <cover.1479844814.git.ldun...@suse.com>:
> [...]
>> The second patch modifies iscsid to treat a
>> SIGTERM just like it had received the "immediate
>> stop" command from iscsiadm (via the "-k"
>> option), simplifying the shutdown of iscsid so
>> that it no longer requires IPC communications.
> 
> Good common practice see to perform an orderly (clean) shutdown on first 
> receipt of SIGTERM; if another SIGTERM arrives a few seconds (time depending 
> on the application) later, a more immediate shutdown should be attempted 
> (still trying to be as clean as possible).

In this case, I think this is overkill since systemd is already managing 
shutdown escalation for us.

Systemd will, by default, send a SIGTERM. I have configured it to send that 
SIGTERM to the main
process only by setting KillMode=mixed in the unit file.

Systemd will then send SIGKILL to all the processes in the process group after 
its default stop
timeout. This timeout defaults to 90 seconds but can of course be configured 
separately if desired
for iscsid.

I believe the best approach may be to handle it exactly like the IPC request 
for shutdown is
handled, i.e. set the “exit the polling loop” flag, then return. If this 
approach does not work
within the timeout period a SIGKILL is going to be received.

> 
> I had implemented such a pattern in a network server, and I'll use it for an 
> example here (forgive!):
> 1st signal prevents accepting new connections; server will shut down if all 
> connections are gone
> 2nd signal will shutdown connections if current requests have been answered
> 3rd signal will terminate active connections (those who transfer data) (i.e. 
> after a recv/send)
> 4th signal will terminate connections blocked on sending or receiving data 
> (i.e. kill an "active" recv/send)
> So eventually the server will arrive in the "1st signal received state" 
> eventually...
> 
> Regards,
> Ulrich
> 
>> 
>> Hannes Reinecke (1):
>>  Use timeout when waiting for responses from iscsid
>> 
>> Lee Duncan (1):
>>  iscsid: treat SIGTERM like "iscsiadm -k 0".
>> 
>> usr/config.h   |  1 +
>> usr/discovery.c| 16 +++---
>> usr/host.c |  2 +-
>> usr/iscsi_sysfs.c  |  1 +
>> usr/iscsiadm.c | 12 ++-
>> usr/iscsid.c   | 29 +++---
>> usr/iscsid_req.c   | 52 
>> +-
>> usr/iscsid_req.h   | 15 +++--
>> usr/iscsistart.c   |  4 ++--
>> usr/session_info.c | 14 +++--
>> usr/session_info.h |  5 +++--
>> 12 files changed, 99 insertions(+), 53 deletions(-)
>> 
>> -- 
>> 1.8.5.6
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "open-iscsi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to open-iscsi+unsubscr...@googlegroups.com.
>> To post to this group, send email to open-iscsi@googlegroups.com.
>> Visit this group at https://groups.google.com/group/open-iscsi.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "open-iscsi" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/open-iscsi/bwoKUjj6cdk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> open-iscsi+unsubscr...@googlegroups.com.
> To post to this group, send email to open-iscsi@googlegroups.com.
> Visit this group at https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCHv2 2/2] iscsid: treat SIGTERM like "iscsiadm -k 0".

[Lee Duncan]

On Nov 23, 2016, at 4:13 AM, Christian Seiler  wrote:
> 
> Hi,
> 
> On 11/22/2016 11:43 PM, leeman.dun...@gmail.com wrote:
>> static void catch_signal(int signo)
>> [...]
>>  switch (signo) {
>>  case SIGTERM:
>> -iscsid_shutdown();
>> +iscsid_shutdown_and_cleanup();
>>  exit(0);
>>  break;
> 
> I think this is not a good idea because most functions called
> here will not be async signal safe, and you are calling them
> from a signal handler. Beforehand this was not a problem since
> iscsid_shutdown() is just a kill of the process group.

The signal is ignored while in the signal handler, and I expect
not to get a SIGTERM storm. But perhaps you are right.

> 
> This might lead to very ugly race condition and deadlocks, and
> the race conditions could cause crashes or even arbitrary
> memory to be overwritten in the worst case. (Think code that
> is in the middle of updating a data structure, and the signal
> comes at a time when the structure is in an inconsistent
> state.)
> 
> Creating async-signal-safe data structures is not impossible
> (as long as atomic operations are available), but very hard to
> do properly, and even harder when shutdown of these data
> structures in a signal handler is to be supported. Writing
> thread-safe code is much, much easier, for example.
> 
> The recommended way of performing complicated actions in
> response to signals in daemons is to have the signal handler
> set a flag (either using atomic operations or with the good
> old "volatile") and have the regular event loop always check
> to see if the flag was changed, and if so initiate a
> shutdown.

I will resubmit the patch series with the 2nd patch updated.

I see now (looking at the code), that I can just set the “exit
the event loop” flag when SIGTERM is received. And it has
the added benefit of being idempotent, so I don’t need to
guard against receiving multiple signals.

> 
> Regards,
> Christian
> 

-- 
Lee-Man
"Reincarnated as love poetry." -- Big Head Todd

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: iscsid shutdown hangs with system when service manually killed

[Lee Duncan]

> On Nov 21, 2016, at 6:14 AM, Hannes Reinecke  wrote:
> 
> On 11/19/2016 08:46 PM, The Lee-Man wrote:
>> In this wonderful new world of systemd, I have an issue with stopping
>> the iscsid service when the daemon has died or been killed.
>> 
>> My setup:
>> * I have an iscsid.socket unit file, which is enabled and started
>> * I have an iscsid.service unit file, which controls the iscsid daemon.
>> This is disabled and not started
>> 
>> Normally, if I run a command like "iscsiadm -m discovery -t st -p
>> SOME-TARGET", systemd notices that iscsiadm is trying to talk to iscsid
>> through the socket, and it starts up iscsid. This is the cool part
>> (IMHO) of systemd socket activation.
>> 
>> When I want to stop iscsid, I can just tell systemctl to do it via
>> "systemctl stop iscsid", and it runs the "ExecStop=" command in the
>> service unit file, which is "iscsiadm -k 0 2" before terminating the
>> daemon process(es).
>> 
>> [NOTE: the "2" here in this command actually does nothing and is
>> ignored, but I copied this from someplace else long ago, and the "2" was
>> present there.]
>> 
>> It is of importance, in this case, that the ExecStop command actually
>> sends an IPC message to the daemon (iscsid) requesting it to cleanly
>> shut itself down. Herein lies the rub.
>> 
>> All of this works great until the daemon happens not to be running. You
>> can simulate this with "kill -TERM $(pidof iscsid)" when the daemon is
>> running. Now you are in a situation where systemd started the service
>> and knows it is now not running, so it seems to send the ExecStop
>> command to cleanly shut it down. This command hangs! It seems to be
>> stuck in an infinite loop trying to send the shutdown command to the
>> daemon, waiting for it to timeout, then trying again. The daemon starts
>> up, sees an IPC error, and exits.
>> 
>> While this clearly seems like a systemd issue, I have found a workaround
>> that looks clean. Well, as clean as the shutdown command is, anyway.
> 
> No, that's not the case.
> This is a plain issue with iscsiadm; it's waiting in 'recv' to receive
> an response packet from iscsid which of course never will come.
> The reason why this becomes an issue now is that systemd holds the
> socket for us, so the socket is available; hence 'recv()' will not
> return with ENOTCONN or somesuch, indicating that the socket isn't present.
> The socket _is_ present, it's just not sending any responses back.
> 
> Attached is a patch for open-iscsi to use 'poll()' before recv(), and
> terminating it if we didn't get a response in time.
> 
> This doesn't do anything from the mentioned socket activation issue for
> iscsid, but at least iscsiadm doesn't hang anymore.
> 
> Cheers,
> 
> Hannes

One issue with the patch. It looks like you might need a “break” added
after the “log_error()” when poll() fails, or it could be an infinite loop:

+   while (len) {
+   struct pollfd pfd;
+
+   pfd.fd = fd;
+   pfd.events = POLLIN;
+   err = poll(, 1, timeout);
+   if (!err) {
+   if (poll_wait)
+   continue;
+   return ISCSI_ERR_ISCSID_NOTCONN;
+   } else if (err < 0) {
+   if (errno == EINTR)
+   continue;
+   log_error("got poll error (%d/%d), daemon died?",
+ err, errno);
+   return ISCSI_ERR_ISCSID_COMM_ERR;
+   } else if (!pfd.revents & POLLIN)
+   continue;
+   err = recv(fd, rsp, sizeof(*rsp), MSG_WAITALL);
+   if (err < 0) {
+   log_error("got read error (%d/%d), daemon died?",
+ err, errno);
   break;   
  <<= Add a break here?
+   } else {
+   len -= err;
+   iscsi_err = rsp->err;
+   }
+   }

I can make that adjustment, if you agree it’s needed, when applying the patch.
-- 
The Lee-Man
Prepare to be unprepared. -- Me

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: RFC: iscsid shutdown hangs with system when service manually killed

[Lee Duncan]

On Nov 20, 2016, at 1:17 AM, Christian Seiler  wrote:
> 
> On 11/19/2016 08:46 PM, The Lee-Man wrote:
>> In this wonderful new world of systemd, I have an issue with stopping the 
>> iscsid service when the daemon has died or been killed.
>> 
>> My setup:
>> * I have an iscsid.socket unit file, which is enabled and started
>> * I have an iscsid.service unit file, which controls the iscsid daemon. 
>> This is disabled and not started
>> 
>> Normally, if I run a command like "iscsiadm -m discovery -t st -p 
>> SOME-TARGET", systemd notices that iscsiadm is trying to talk to iscsid 
>> through the socket, and it starts up iscsid. This is the cool part (IMHO) 
>> of systemd socket activation.
>> 
>> When I want to stop iscsid, I can just tell systemctl to do it via 
>> "systemctl stop iscsid", and it runs the "ExecStop=" command in the service 
>> unit file, which is "iscsiadm -k 0 2" before terminating the daemon 
>> process(es).
>> 
>> [NOTE: the "2" here in this command actually does nothing and is ignored, 
>> but I copied this from someplace else long ago, and the "2" was present 
>> there.]
>> 
>> It is of importance, in this case, that the ExecStop command actually sends 
>> an IPC message to the daemon (iscsid) requesting it to cleanly shut itself 
>> down. Herein lies the rub.
>> 
>> All of this works great until the daemon happens not to be running. You can 
>> simulate this with "kill -TERM $(pidof iscsid)" when the daemon is running. 
>> Now you are in a situation where systemd started the service and knows it 
>> is now not running, so it seems to send the ExecStop command to cleanly 
>> shut it down. This command hangs! It seems to be stuck in an infinite loop 
>> trying to send the shutdown command to the daemon, waiting for it to 
>> timeout, then trying again. The daemon starts up, sees an IPC error, and 
>> exits.
> 
> The problem here is that iscsiadm tries to connect to the iSCSI socket.
> This triggers systemd's socket activation, but systemd doesn't allow
> conflicting jobs (the systemd terminology for an operation) to execute
> at the same time, so it enqueues the start job due to socket activation
> so that it will be executed _after_ the current stop job is complete.
> 
> Unfortunately iscsiadm hangs until it gets a reply from the socket, so
> the stop job hangs until the start job has been executed again.

In my case this can become an infinite loop.

> 
>> While this clearly seems like a systemd issue, I have found a workaround 
>> that looks clean. Well, as clean as the shutdown command is, anyway. This 
>> involves:
>> 
>> * modifying the "iscsiadm -k" command to require passing in the PID of the 
>> daemon to be killed
>> * modifying the iscsiadm to only call kill_iscsid() if positive PID is 
>> passed in, and that PID exists. It verifies this by sending a blank signal 
>> to the process.
>> * modifying the iscsid.service systemd unit file so that the ExecStop 
>> command becomes "iscsiadm -k 0 $MAINPID"
> 
> That seems like a reasonable way to work around this problem.
> 
>> I know other distributions are having been dealing with iscsid service 
>> shutdown issues with systemd for a while now. Perhaps somebody else has a 
>> better solution?
> 
> In Debian we just  don't use socket activation for iscsid, but just
> install a systemd service file alone. I think I had trouble with
> socket activation (may well have been the same problem you had, I
> don't remember), but when I actually thought about it in more detail,
> I didn't see the point in having socket activation for iscsid in the
> first place, at least not in Debian, so I just dropped that part.
> 
> The rationale for why we don't make use of socket activation:
> 
> - we unconditionally execute iscsiadm -m node --loginall=automatic
>   at boot if open-iscsi is installed
> 
> - that will cause iscsid to start at boot even with socket
>   activation, and stay active for the entirety of the running
>   system
> 
>  => this means that even if there are no configured sessions
> we still don't save time at boot
> 
> - since iscsid is required to be kept around for session recovery
>   it can't auto-exit on idle, because an active session means it
>   should never be idle (and there's currently no support in the
>   code for that)
> 
> - the corner case where people have iscsid installed but don't use
>   it didn't seem that relevant, especially since iscsid uses less
>   than 4 MiB of RAM on my system if unused
> 
> - but even if we were to make iscsiadm not contact iscsid when
>   using --loginall=automatic and no sessions are configured, this
>   still wouldn't help us, because there still could be sessions
>   configured in the initramfs, for which we'd want to have iscsid
>   running at boot to perform session recovery
> 
> The only thing I could think of to make this at least somewhat
> useful is to have iscsid exit if there are no active sessions and
> a certain time has passed => 

Re: RFC: iscsid shutdown hangs with system when service manually killed

[Lee Duncan]

> On Nov 19, 2016, at 12:57 PM, Vanush Misha Paturyan  wrote:
> 
> On Sat, 19 Nov 2016 at 19:46 The Lee-Man  > wrote:
> In this wonderful new world of systemd, I have an issue with stopping the 
> iscsid service when the daemon has died or been killed.
> 
> My setup:
> * I have an iscsid.socket unit file, which is enabled and started
> * I have an iscsid.service unit file, which controls the iscsid daemon. This 
> is disabled and not started
> 
> Normally, if I run a command like "iscsiadm -m discovery -t st -p 
> SOME-TARGET", systemd notices that iscsiadm is trying to talk to iscsid 
> through the socket, and it starts up iscsid. This is the cool part (IMHO) of 
> systemd socket activation.
> 
> When I want to stop iscsid, I can just tell systemctl to do it via "systemctl 
> stop iscsid", and it runs the "ExecStop=" command in the service unit file, 
> which is "iscsiadm -k 0 2" before terminating the daemon process(es).
> 
> [NOTE: the "2" here in this command actually does nothing and is ignored, but 
> I copied this from someplace else long ago, and the "2" was present there.]
> 
> It is of importance, in this case, that the ExecStop command actually sends 
> an IPC message to the daemon (iscsid) requesting it to cleanly shut itself 
> down. Herein lies the rub.
> 
> All of this works great until the daemon happens not to be running. You can 
> simulate this with "kill -TERM $(pidof iscsid)" when the daemon is running. 
> Now you are in a situation where systemd started the service and knows it is 
> now not running, so it seems to send the ExecStop command to cleanly shut it 
> down. This command hangs! It seems to be stuck in an infinite loop trying to 
> send the shutdown command to the daemon, waiting for it to timeout, then 
> trying again. The daemon starts up, sees an IPC error, and exits.
> 
> While this clearly seems like a systemd issue, I have found a workaround that 
> looks clean. Well, as clean as the shutdown command is, anyway. This involves:
>  
> How is this systemd's issue? From what you wrote above, it looks like isciadm 
> -k is trying to stop iscsid daemon without even checking if iscsid daemon is 
> running.

Systemd claims to be in charge of the service. Systemd knows whether or not the 
service is running. There should be no need to stop the service, in this case, 
since systemd knows it already is not running.

>  
> * modifying the "iscsiadm -k" command to require passing in the PID of the 
> daemon to be killed
> 
> is it possible to run more than one daemon on the same server? Maybe it will 
> be enough just to modify iscsiadm to check first if daemon is running before 
> trying to stop it?

No, right now there is only one iscsid daemon, normally. Systemd has no concept 
of multiple daemons for iscsi.

Normally it is the job of iscsiadm to send messages for this kind of thing to 
iscsid. Systemd normally starts iscsid if it is not running, so iscsiadm 
doesn’t normally need to worry about that. Plus, if systemd is not running 
iscsiadm has a configuration option to start iscsid manually, if needed. This 
handles every other case of iscsiadm talking to iscsid except this one.

I have prototyped a patch that has iscsiadm check to see if iscsid is running 
before trying to kill it. It uses “kill(0)” but requires the caller to pass in 
the PID of iscsid. If you can think of a better and simpler way for iscsiadm to 
detect if iscsid is running, I’m open for a different approach.

Perhaps I should post my patches?

>  
> Misha
> 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: iscsi: make mutex for target scanning and unbinding per-session

[Lee Duncan]

> On Nov 10, 2016, at 1:22 PM, Chris Leech  wrote:
> 
> On Thu, Nov 10, 2016 at 10:00:54AM -0800, The Lee-Man wrote:
>> On Monday, November 7, 2016 at 11:22:23 AM UTC-7, Chris Leech wrote:
>>> 
>>> Currently the iSCSI transport class synchronises target scanning and 
>>> unbinding with a host level mutex.  For multi-session hosts (offloading 
>>> iSCSI HBAs) connecting to storage arrays that may implement one 
>>> target-per-lun, this can result in the target scan work for hundreds of 
>>> sessions being serialized behind a single mutex.  With slow enough 
>>> response times, this can cause scan requests initiated from userspace to 
>>> block on the mutex long enough to trigger 120 sec hung task warnings. 
>>> 
>>> I can't see any reason not to move this to a session level mutex and let 
>>> the target scans run in parallel, speeding up connecting to a large 
>>> number of targets.  Note that as iscsi_tcp creates a virtual host for 
>>> each session, software iSCSI is effectively doing this already. 
>>> 
>> 
>> I understood the reason for this mutex was to protect against the case
>> where there are multiple paths to a target. In such cases, you can get
>> simultaneous access to sysfs attributes (files), which can cause errors,
>> i.e. two threads trying to write an attribute at the same time, or one
>> changing an attribute while another reads or removes it.
> 
> This particular mutex is only serializing scanning targets for devices,
> and used in __iscsi_unbind_session to ensure that no scans are in
> progress adding new scsi devices while we're trying to remove a target.

Hot unplug?

> 
>> I worry that changing it will not address those issues.
>> 
>> [Side note: we *really* need a test suite that somehow includes
>> cases like this.]
>> 
>>> 

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

[PATCHv2] MAINTAINERS: Update open-iscsi maintainers

[Lee Duncan]

Chris Leech and I are taking over as open-iscsi maintainers.

Changes since v1:
 * Updated URL to open-iscsi.com
 * Removed git repository, since code in tree
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 01bff8ea28d8..81384a2562e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6448,10 +6448,10 @@ S:  Maintained
 F: drivers/firmware/iscsi_ibft*
 
 ISCSI
-M: Mike Christie <micha...@cs.wisc.edu>
+M:     Lee Duncan <ldun...@suse.com>
+M: Chris Leech <cle...@redhat.com>
 L: open-iscsi@googlegroups.com
-W: www.open-iscsi.org
-T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git
+W: www.open-iscsi.com
 S: Maintained
 F: drivers/scsi/*iscsi*
 F: include/scsi/*iscsi*
-- 
2.1.4

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: [PATCH] MAINTAINERS: Update open-iscsi maintainers

[Lee Duncan]

[Added linux-scsi to the cc list.]

I will resubmit an updated version of this patch.

On 09/23/2016 02:34 PM, Lee Duncan wrote:
> Chris Leech and I are taking over open-iscsi
> maintenance from Mike Christie.
> 
> Signed-off-by: Lee Duncan <ldun...@suse.com>
> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 01bff8ea28d8..0afaf42d5416 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6448,7 +6448,8 @@ S:  Maintained
>  F:   drivers/firmware/iscsi_ibft*
>  
>  ISCSI
> -M:   Mike Christie <micha...@cs.wisc.edu>
> +M:   Lee Duncan <ldun...@suse.com>
> +M:   Chris Leech <cle...@redhat.com>
>  L:   open-iscsi@googlegroups.com
>  W:   www.open-iscsi.org
>  T:   git 
> git://git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git
> 

-- 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

[PATCH] MAINTAINERS: Update open-iscsi maintainers

[Lee Duncan]

Chris Leech and I are taking over open-iscsi
maintenance from Mike Christie.

Signed-off-by: Lee Duncan <ldun...@suse.com>
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 01bff8ea28d8..0afaf42d5416 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6448,7 +6448,8 @@ S:Maintained
 F: drivers/firmware/iscsi_ibft*
 
 ISCSI
-M: Mike Christie <micha...@cs.wisc.edu>
+M:     Lee Duncan <ldun...@suse.com>
+M: Chris Leech <cle...@redhat.com>
 L: open-iscsi@googlegroups.com
 W: www.open-iscsi.org
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/mnc/linux-2.6-iscsi.git
-- 
2.1.4

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.