Re: Broken pipe on my target. Is there any option on my initiator to fix it?

2015-05-13 Thread Felipe Gutierrez
I am using async option to export me nfs 
disk. http://unixhelp.ed.ac.uk/CGI/man-cgi?exports

This help all writes on the disk to be very fast.


On Saturday, May 9, 2015 at 2:05:19 PM UTC-3, Felipe Gutierrez wrote:

 Hi, I am using jscsi.org target and open-iscsi initiator. Through NFS I 
 can copy a bunch of files and it seems ok. When I execute a virtual machine 
 from vmware (vmware - NFS - open-iscsi - target jscsi) the target throws 
 a broken pipe some times. THe initiator reestabilish the connection, but 
 this broken pipe is corrupting my VM file system.

 On a good work my target sends SCSIResponseParser PDU and after that 
 receives SCSICommandParser PDU from the initiator. When the broken pipe is 
 up to happen the target sends SCSIResponseParser PDU and does not receive 
 SCSICommandParser PDU. Instead of it, the target receives after 5 seconds 
 NOPOutParser PDU, and sends  NOPInParser PDU. After 60 seconds my target 
 receives TaskManagementFunctionRequestParser PDU with OpCode: 0x2, which 
 means to abort the task. So, the target do what the initiator is asking. 
 The broken pipe happens ans a nes connections is estabilished.

 My question is, why the initiator does not keep the comunication after the 
 SCSIResponseParser PDU sent by the target? Is there any way to see if this 
 message is wrong? Or any initiator log error?
 Here is the target debug.

 (228)19:19:01 DEBUG [main] fullfeature.WriteStage - PDU sent 4:   
 ParserClass: SCSIResponseParser
   ImmediateFlag: false
   OpCode: 0x21
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2810
   Response: 0x0
   SNACK TAG: 0x0
   StatusSequenceNumber: 0xc8a
   ExpectedCommandSequenceNumber: 0xc6e
   MaximumCommandSequenceNumber: 0xc6e
   ExpDataSN: 0x0
   BidirectionalReadResidualOverflow: false
   BidirectionalReadResidualUnderflow: false
   ResidualOverflow: false
   ResidualUnderflow: false
   ResidualCount: 0x0
   Bidirectional Read Residual Count: 0x0

 (273)19:19:06 DEBUG [main] connection.TargetSenderWorker - Receiving this 
 PDU:
   ParserClass: NOPOutParser
   ImmediateFlag: true
   OpCode: 0x0
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2910
   LUN: 0x0
   Target Transfer Tag: 0x
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc8b

 (144)19:19:06 DEBUG [main] connection.TargetSenderWorker - 
 connection.getStatusSequenceNumber: 3211
 (167)19:19:06 DEBUG [main] connection.TargetSenderWorker - Sending this 
 PDU:
   ParserClass: NOPInParser
   ImmediateFlag: false
   OpCode: 0x20
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2910
   LUN: 0x0
   Target Transfer Tag: 0x
   StatusSequenceNumber: 0xc8b
   ExpectedCommandSequenceNumber: 0xc6e
   MaximumCommandSequenceNumber: 0xc6e

 (228)19:19:11 DEBUG [main] connection.TargetSenderWorker - Receiving this 
 PDU:
   ParserClass: NOPOutParser
   ImmediateFlag: true
   OpCode: 0x0
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2a10
   LUN: 0x0
   Target Transfer Tag: 0x
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc8c


 
 ...
 ...
 ...
 (228)19:20:02 DEBUG [main] connection.TargetSenderWorker - Receiving this 
 PDU:
   ParserClass: TaskManagementFunctionRequestParser
   ImmediateFlag: true
   OpCode: 0x2
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x3610
   LUN: 0x0
   Referenced Task Tag: 0x6b10
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc98
   RefCmdSN: 0xab6
   ExpDataSN: 0x0


 Thanks, Felipe


-- 
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.


Re: Broken pipe on my target. Is there any option on my initiator to fix it?

2015-05-13 Thread Donald Williams
Hello Felipe,

 I'm not sure about anyone else, but I wouldn't expect that tweaking the
iSCSI settings you've been talking about will improve this.

 Have you tested just connecting from server to storage via iSCSI?   Take
NFS out of the picture.  iSCSI is very dependent on the network.  What kind
of switch are you using?   Is flowcontrol enabled?Have you configured
MPIO?

 With just iSCSI you can potentially getting better triage data from the
iSCSId logs.

 don



On Wed, May 13, 2015 at 10:24 AM, Felipe Gutierrez fel...@usto.re wrote:

 I am using async option to export me nfs disk.
 http://unixhelp.ed.ac.uk/CGI/man-cgi?exports

 This help all writes on the disk to be very fast.


 On Saturday, May 9, 2015 at 2:05:19 PM UTC-3, Felipe Gutierrez wrote:

 Hi, I am using jscsi.org target and open-iscsi initiator. Through NFS I
 can copy a bunch of files and it seems ok. When I execute a virtual machine
 from vmware (vmware - NFS - open-iscsi - target jscsi) the target throws
 a broken pipe some times. THe initiator reestabilish the connection, but
 this broken pipe is corrupting my VM file system.

 On a good work my target sends SCSIResponseParser PDU and after that
 receives SCSICommandParser PDU from the initiator. When the broken pipe is
 up to happen the target sends SCSIResponseParser PDU and does not receive
 SCSICommandParser PDU. Instead of it, the target receives after 5 seconds
 NOPOutParser PDU, and sends  NOPInParser PDU. After 60 seconds my target
 receives TaskManagementFunctionRequestParser PDU with OpCode: 0x2, which
 means to abort the task. So, the target do what the initiator is asking.
 The broken pipe happens ans a nes connections is estabilished.

 My question is, why the initiator does not keep the comunication after
 the SCSIResponseParser PDU sent by the target? Is there any way to see if
 this message is wrong? Or any initiator log error?
 Here is the target debug.

 (228)19:19:01 DEBUG [main] fullfeature.WriteStage - PDU sent 4:
 ParserClass: SCSIResponseParser
   ImmediateFlag: false
   OpCode: 0x21
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2810
   Response: 0x0
   SNACK TAG: 0x0
   StatusSequenceNumber: 0xc8a
   ExpectedCommandSequenceNumber: 0xc6e
   MaximumCommandSequenceNumber: 0xc6e
   ExpDataSN: 0x0
   BidirectionalReadResidualOverflow: false
   BidirectionalReadResidualUnderflow: false
   ResidualOverflow: false
   ResidualUnderflow: false
   ResidualCount: 0x0
   Bidirectional Read Residual Count: 0x0

 (273)19:19:06 DEBUG [main] connection.TargetSenderWorker - Receiving this
 PDU:
   ParserClass: NOPOutParser
   ImmediateFlag: true
   OpCode: 0x0
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2910
   LUN: 0x0
   Target Transfer Tag: 0x
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc8b

 (144)19:19:06 DEBUG [main] connection.TargetSenderWorker -
 connection.getStatusSequenceNumber: 3211
 (167)19:19:06 DEBUG [main] connection.TargetSenderWorker - Sending this
 PDU:
   ParserClass: NOPInParser
   ImmediateFlag: false
   OpCode: 0x20
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2910
   LUN: 0x0
   Target Transfer Tag: 0x
   StatusSequenceNumber: 0xc8b
   ExpectedCommandSequenceNumber: 0xc6e
   MaximumCommandSequenceNumber: 0xc6e

 (228)19:19:11 DEBUG [main] connection.TargetSenderWorker - Receiving this
 PDU:
   ParserClass: NOPOutParser
   ImmediateFlag: true
   OpCode: 0x0
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2a10
   LUN: 0x0
   Target Transfer Tag: 0x
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc8c


 
 ...
 ...
 ...
 (228)19:20:02 DEBUG [main] connection.TargetSenderWorker - Receiving this
 PDU:
   ParserClass: TaskManagementFunctionRequestParser
   ImmediateFlag: true
   OpCode: 0x2
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x3610
   LUN: 0x0
   Referenced Task Tag: 0x6b10
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc98
   RefCmdSN: 0xab6
   ExpDataSN: 0x0


 Thanks, Felipe

  --
 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 http://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 

Re: Broken pipe on my target. Is there any option on my initiator to fix it?

2015-05-13 Thread Felipe Gutierrez
Hi Donald, thanks for reply,

I realized the my problem was the NFS. The default mode is sync, now I am
exporting my NFS async at /etc/export. It is very dangers because I can
corrupt my data, but I am gonna put a firewall to these two machines.

Thanks again!
Felipe

On Wed, May 13, 2015 at 6:11 PM, Donald Williams don.e.willi...@gmail.com
wrote:

 Hello Felipe,

  I'm not sure about anyone else, but I wouldn't expect that tweaking the
 iSCSI settings you've been talking about will improve this.

  Have you tested just connecting from server to storage via iSCSI?   Take
 NFS out of the picture.  iSCSI is very dependent on the network.  What kind
 of switch are you using?   Is flowcontrol enabled?Have you configured
 MPIO?

  With just iSCSI you can potentially getting better triage data from the
 iSCSId logs.

  don



 On Wed, May 13, 2015 at 10:24 AM, Felipe Gutierrez fel...@usto.re wrote:

 I am using async option to export me nfs disk.
 http://unixhelp.ed.ac.uk/CGI/man-cgi?exports

 This help all writes on the disk to be very fast.


 On Saturday, May 9, 2015 at 2:05:19 PM UTC-3, Felipe Gutierrez wrote:

 Hi, I am using jscsi.org target and open-iscsi initiator. Through NFS I
 can copy a bunch of files and it seems ok. When I execute a virtual machine
 from vmware (vmware - NFS - open-iscsi - target jscsi) the target throws
 a broken pipe some times. THe initiator reestabilish the connection, but
 this broken pipe is corrupting my VM file system.

 On a good work my target sends SCSIResponseParser PDU and after that
 receives SCSICommandParser PDU from the initiator. When the broken pipe is
 up to happen the target sends SCSIResponseParser PDU and does not receive
 SCSICommandParser PDU. Instead of it, the target receives after 5 seconds
 NOPOutParser PDU, and sends  NOPInParser PDU. After 60 seconds my target
 receives TaskManagementFunctionRequestParser PDU with OpCode: 0x2, which
 means to abort the task. So, the target do what the initiator is asking.
 The broken pipe happens ans a nes connections is estabilished.

 My question is, why the initiator does not keep the comunication after
 the SCSIResponseParser PDU sent by the target? Is there any way to see if
 this message is wrong? Or any initiator log error?
 Here is the target debug.

 (228)19:19:01 DEBUG [main] fullfeature.WriteStage - PDU sent 4:
 ParserClass: SCSIResponseParser
   ImmediateFlag: false
   OpCode: 0x21
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2810
   Response: 0x0
   SNACK TAG: 0x0
   StatusSequenceNumber: 0xc8a
   ExpectedCommandSequenceNumber: 0xc6e
   MaximumCommandSequenceNumber: 0xc6e
   ExpDataSN: 0x0
   BidirectionalReadResidualOverflow: false
   BidirectionalReadResidualUnderflow: false
   ResidualOverflow: false
   ResidualUnderflow: false
   ResidualCount: 0x0
   Bidirectional Read Residual Count: 0x0

 (273)19:19:06 DEBUG [main] connection.TargetSenderWorker - Receiving
 this PDU:
   ParserClass: NOPOutParser
   ImmediateFlag: true
   OpCode: 0x0
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2910
   LUN: 0x0
   Target Transfer Tag: 0x
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc8b

 (144)19:19:06 DEBUG [main] connection.TargetSenderWorker -
 connection.getStatusSequenceNumber: 3211
 (167)19:19:06 DEBUG [main] connection.TargetSenderWorker - Sending this
 PDU:
   ParserClass: NOPInParser
   ImmediateFlag: false
   OpCode: 0x20
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2910
   LUN: 0x0
   Target Transfer Tag: 0x
   StatusSequenceNumber: 0xc8b
   ExpectedCommandSequenceNumber: 0xc6e
   MaximumCommandSequenceNumber: 0xc6e

 (228)19:19:11 DEBUG [main] connection.TargetSenderWorker - Receiving
 this PDU:
   ParserClass: NOPOutParser
   ImmediateFlag: true
   OpCode: 0x0
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x2a10
   LUN: 0x0
   Target Transfer Tag: 0x
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc8c


 
 ...
 ...
 ...
 (228)19:20:02 DEBUG [main] connection.TargetSenderWorker - Receiving
 this PDU:
   ParserClass: TaskManagementFunctionRequestParser
   ImmediateFlag: true
   OpCode: 0x2
   FinalFlag: true
   TotalAHSLength: 0x0
   DataSegmentLength: 0x0
   InitiatorTaskTag: 0x3610
   LUN: 0x0
   Referenced Task Tag: 0x6b10
   CommandSequenceNumber: 0xc6e
   ExpectedStatusSequenceNumber: 0xc98
   RefCmdSN: 0xab6
   ExpDataSN: 0x0


 Thanks, Felipe

  --
 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 http://groups.google.com/group/open-iscsi.
 For more options, visit 

[RFC PATCH 2/4] iscsi: sysfs filtering by network namespace

2015-05-13 Thread Chris Leech
This makes the iscsi_host, iscsi_session, iscsi_connection, 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.
---
 drivers/scsi/scsi_transport_iscsi.c | 114 ++--
 include/scsi/scsi_transport_iscsi.h |   1 +
 2 files changed, 98 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index 88a3347..2b146cb 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -161,9 +161,33 @@ static void iscsi_endpoint_release(struct device *dev)
kfree(ep);
 }
 
+static const struct net *iscsi_host_net(struct iscsi_cls_host *ihost)
+{
+   return ihost-netns;
+}
+
+static const struct net *iscsi_endpoint_net(struct iscsi_endpoint *ep)
+{
+   struct iscsi_cls_conn *cls_conn = ep-conn;
+   struct iscsi_cls_session *cls_session = iscsi_conn_to_session(cls_conn);
+   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_endpoint_namespace(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 = net_ns_type_operations,
+   .namespace = iscsi_endpoint_namespace,
 };
 
 static ssize_t
@@ -1570,6 +1594,7 @@ static int iscsi_setup_host(struct transport_container 
*tc, struct device *dev,
memset(ihost, 0, sizeof(*ihost));
atomic_set(ihost-nr_scans, 0);
mutex_init(ihost-mutex);
+   ihost-netns = init_net;
 
iscsi_bsg_host_add(shost, ihost);
/* ignore any bsg add error - we just can't do sgio */
@@ -1590,23 +1615,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);
-
-static DECLARE_TRANSPORT_CLASS(iscsi_session_class,
-  iscsi_session,
-  NULL,
-  NULL,
-  NULL);
-
-static DECLARE_TRANSPORT_CLASS(iscsi_connection_class,
-  iscsi_connection,
-  NULL,
-  NULL,
-  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(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,
+ net_ns_type_operations,
+ iscsi_host_namespace);
+
+static const 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(struct device *dev)
+{
+   struct iscsi_cls_session *cls_session = transport_class_to_session(dev);
+
+   return iscsi_sess_net(cls_session);
+}
+
+static DECLARE_TRANSPORT_CLASS_NS(iscsi_session_class,
+ iscsi_session,
+ NULL,
+ NULL,
+ NULL,
+ net_ns_type_operations,
+ iscsi_sess_namespace);
+
+static const struct net *iscsi_conn_net(struct iscsi_cls_conn *cls_conn)
+{
+   struct 

[RFC PATCH 0/4] Make iSCSI network namespace aware

2015-05-13 Thread Chris Leech
I've had a few reports of people trying to run iscsid in a container, which
doesn't work at all when using network namespaces.  This is the start of me
looking at what it would take to make that work, and if it makes sense at all.

The first issue is that the kernel side of the iSCSI netlink control protocol
only operates in the initial network namespace.  But beyond that, if we allow
iSCSI to be managed within a namespace we need to decide what that means.  I
think it makes the most sense to isolate the iSCSI host, along with it's
associated endpoints, connections, and sessions, to a network namespace and
allow multiple instances of the userspace tools to exist in separate namespaces
managing separate hosts.

It works well for iscsi_tcp, which creates a host per session.  There's no
attempt to manage sessions on offloading hosts independently, although future
work could include the ability to move an entire host to a new namespace like
is supported for network devices.

This is only about the structures and functionality involved in maintaining the
iSCSI session, the SCSI host along with it's discovered targets and devices has
no association with network namespaces.

These patches are functional, but not complete.  There's no isolation enforced
in the kernel just yet, so it relies on well behaved userspace.  I plan on
fixing that, but wanted some feedback on the idea and approach so far.

Thanks,
Chris

Chris Leech (4):
  iscsi: create per-net iscsi nl kernel sockets
  iscsi: sysfs filtering by network namespace
  iscsi: make all netlink multicast namespace aware
  iscsi: set netns for iscsi_tcp hosts

 drivers/scsi/iscsi_tcp.c|   7 +
 drivers/scsi/scsi_transport_iscsi.c | 264 +---
 include/scsi/scsi_transport_iscsi.h |   2 +
 3 files changed, 222 insertions(+), 51 deletions(-)

-- 
2.1.0

-- 
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.


[RFC PATCH 1/4] iscsi: create per-net iscsi nl kernel sockets

2015-05-13 Thread Chris Leech
Prepare iSCSI netlink to operate in multiple namespaces.
---
 drivers/scsi/scsi_transport_iscsi.c | 67 +++--
 1 file changed, 57 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index 67d43e3..88a3347 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -26,6 +26,8 @@
 #include linux/bsg-lib.h
 #include linux/idr.h
 #include net/tcp.h
+#include net/net_namespace.h
+#include net/netns/generic.h
 #include scsi/scsi.h
 #include scsi/scsi_host.h
 #include scsi/scsi_device.h
@@ -1606,7 +1608,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);
@@ -2338,11 +2344,23 @@ 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(init_net, skb, group, gfp);
+}
+
 int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct iscsi_hdr *hdr,
   char *data, uint32_t data_size)
 {
@@ -4505,13 +4523,42 @@ int iscsi_unregister_transport(struct iscsi_transport 
*tt)
 }
 EXPORT_SYMBOL_GPL(iscsi_unregister_transport);
 
-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, cfg);
+   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   = iscsi_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);
 
@@ -4545,8 +4592,8 @@ static __init int iscsi_transport_init(void)
if (err)
goto unregister_session_class;
 
-   nls = netlink_kernel_create(init_net, NETLINK_ISCSI, cfg);
-   if (!nls) {
+   err = register_pernet_subsys(iscsi_net_ops);
+   if (err) {
err = -ENOBUFS;
goto unregister_flashnode_bus;
}
@@ -4554,13 +4601,13 @@ static __init int iscsi_transport_init(void)
iscsi_eh_timer_workq = create_singlethread_workqueue(iscsi_eh);
if (!iscsi_eh_timer_workq) {
err = -ENOMEM;
-   goto release_nls;
+   goto unregister_pernet_subsys;
}
 
return 0;
 
-release_nls:
-   netlink_kernel_release(nls);
+unregister_pernet_subsys:
+   unregister_pernet_subsys(iscsi_net_ops);
 unregister_flashnode_bus:
bus_unregister(iscsi_flashnode_bus);
 unregister_session_class:
@@ -4581,7 +4628,7 @@ unregister_transport_class:
 static void __exit iscsi_transport_exit(void)
 {
destroy_workqueue(iscsi_eh_timer_workq);
-   netlink_kernel_release(nls);
+   unregister_pernet_subsys(iscsi_net_ops);
bus_unregister(iscsi_flashnode_bus);
transport_class_unregister(iscsi_connection_class);
transport_class_unregister(iscsi_session_class);
-- 
2.1.0

-- 
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.


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

2015-05-13 Thread Chris Leech
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.
---
 drivers/scsi/scsi_transport_iscsi.c | 92 -
 1 file changed, 61 insertions(+), 31 deletions(-)

diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index 2b146cb..4fdd4bf 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2424,8 +2424,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(const struct net *net, struct sk_buff *skb,
+   uint32_t group, gfp_t gfp)
 {
struct sock *nls;
struct iscsi_net *isn;
@@ -2435,12 +2435,6 @@ iscsi_multicast_netns(struct net *net, struct sk_buff 
*skb,
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(init_net, skb, group, gfp);
-}
-
 int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct iscsi_hdr *hdr,
   char *data, uint32_t data_size)
 {
@@ -2449,6 +2443,7 @@ int iscsi_recv_pdu(struct iscsi_cls_conn *conn, struct 
iscsi_hdr *hdr,
struct iscsi_uevent *ev;
char *pdu;
struct iscsi_internal *priv;
+   const struct net *netns;
int len = nlmsg_total_size(sizeof(*ev) + sizeof(struct iscsi_hdr) +
   data_size);
 
@@ -2475,7 +2470,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);
+   netns = iscsi_conn_net(conn);
+   return iscsi_multicast_skb(netns, skb, ISCSI_NL_GRP_ISCSID, GFP_ATOMIC);
 }
 EXPORT_SYMBOL_GPL(iscsi_recv_pdu);
 
@@ -2486,6 +2482,7 @@ int iscsi_offload_mesg(struct Scsi_Host *shost,
struct nlmsghdr *nlh;
struct sk_buff *skb;
struct iscsi_uevent *ev;
+   const struct net *netns;
int len = nlmsg_total_size(sizeof(*ev) + data_size);
 
skb = alloc_skb(len, GFP_ATOMIC);
@@ -2510,7 +2507,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);
+   netns = iscsi_host_net(shost-shost_data);
+   return iscsi_multicast_skb(netns, skb, ISCSI_NL_GRP_UIP, GFP_ATOMIC);
 }
 EXPORT_SYMBOL_GPL(iscsi_offload_mesg);
 
@@ -2520,6 +2518,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;
+   const struct net *netns;
int len = nlmsg_total_size(sizeof(*ev));
 
priv = iscsi_if_transport_lookup(conn-transport);
@@ -2541,7 +2540,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);
+   netns = iscsi_conn_net(conn);
+   iscsi_multicast_skb(netns, skb, ISCSI_NL_GRP_ISCSID, GFP_ATOMIC);
 
iscsi_cls_conn_printk(KERN_INFO, conn, detected conn error (%d)\n,
  error);
@@ -2555,6 +2555,7 @@ void iscsi_conn_login_event(struct iscsi_cls_conn *conn,
struct sk_buff  *skb;
struct iscsi_uevent *ev;
struct iscsi_internal *priv;
+   const struct net *netns;
int len = nlmsg_total_size(sizeof(*ev));
 
priv = iscsi_if_transport_lookup(conn-transport);
@@ -2575,7 +2576,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);
+
+   netns = iscsi_conn_net(conn);
+   iscsi_multicast_skb(netns, skb, ISCSI_NL_GRP_ISCSID, GFP_ATOMIC);
 
iscsi_cls_conn_printk(KERN_INFO, conn, detected conn login (%d)\n,
  state);
@@ -2586,11 +2589,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;
+   const struct net *netns;
struct nlmsghdr *nlh;
struct sk_buff *skb;
struct iscsi_uevent *ev;
int len = nlmsg_total_size(sizeof(*ev) + data_size);
 
+   shost = scsi_host_lookup(host_no);
+   

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

2015-05-13 Thread Chris Leech
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.
---
 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 0b8af18..ebe99da 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -948,6 +948,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,
@@ -1003,6 +1008,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 4fdd4bf..791aacd 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -1590,11 +1590,16 @@ 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));
atomic_set(ihost-nr_scans, 0);
mutex_init(ihost-mutex);
-   ihost-netns = init_net;
+   if (transport-get_netns)
+   ihost-netns = transport-get_netns(shost);
+   else
+   ihost-netns = init_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 860ac0c..878bcf2 100644
--- a/include/scsi/scsi_transport_iscsi.h
+++ b/include/scsi/scsi_transport_iscsi.h
@@ -168,6 +168,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.1.0

-- 
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.