Re: [PATCH 11/11] iscsi: force destroy sesions when a network namespace exits
On 4/11/23 20:19, Chris Leech wrote: On Tue, Apr 11, 2023 at 08:21:22AM +0200, Hannes Reinecke wrote: On 4/10/23 21:10, Chris Leech wrote: The namespace is gone, so there is no userspace to clean up. Force close all the sessions. This should be enough for software transports, there's no implementation of migrating physical iSCSI hosts between network namespaces currently. Ah, you shouldn't have mentioned that. (Not quite sure how being namespace-aware relates to migration, though.) We should be checking/modifying the iSCSI offload drivers, too. But maybe with a later patch. I shouldn't have left that opening ;-) The idea with this design is to keep everything rooted on the iscsi_host, and for physical HBAs those stay assigned to init_net. With this patch set, offload drivers remain unusable in a net namespace other than init_net. They simply are not visible. By migration, I was implying the possibilty of assigment of an HBA iscsi_host into a namespace like you can do with a network interface. Such an iscsi_host would then need to be migrated back to init_net on namespace exit. I don't think it works to try and share an iscsi_host across namespaces, and manage different sessions. The iSCSI HBAs have a limited number of network configurations, exposed as iscsi_iface objects, and I don't want to go down the road of figuring out how to share those. Ah, yes, indeed. Quite some iSCSI offloads create the network session internally (or don't even have one), so making them namespace aware will be tricky. But then I guess we should avoid creating offload sessions from other namespaces; preferably by a patch for the kernel such that userspace can run unmodified. Cheers, Hannes -- Dr. Hannes ReineckeKernel Storage Architect h...@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman -- 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/e7b55e2d-4bd1-eabe-43b6-ef00da69935a%40suse.de.
Re: [RFC PATCH 5/9] iscsi: set netns for iscsi_tcp hosts
On 4/11/23 02:21, Chris Leech wrote:
On Tue, Mar 14, 2023 at 05:29:25PM +0100, Hannes Reinecke wrote:
On 2/8/23 18:40, Lee Duncan wrote:
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.
And indeed, I'd rather use the namespace from the iscsi netlink socket.
If you use the namespace from session creation you'd better hope that
this function is not called from a workqueue ...
The cleanest way I see to do this is to split the transport
session_create function between bound and unbound, instead of checking
for a NULL ep. That should cleanly serperate out the host-per-session
behavior of iscsi_tcp, so we can pass in the namespace without changing
the other drivers.
This is what that looks like on top of the existing patches, but we can
merge it in and rearrange if desired.
- Chris
---
Distinguish between bound and unbound session creation with different
transport functions, instead of just checking for a NULL endpoint.
This let's the transport code pass the network namespace into the
unbound session creation of iscsi_tcp, without changing the offloading
drivers which all expect an bound endpoint.
iSER has compatibility checks to work without a bound endpoint, so
expose both transport functions there.
Signed-off-by: Chris Leech
---
drivers/infiniband/ulp/iser/iscsi_iser.c | 41 +---
drivers/scsi/iscsi_tcp.c | 16 -
drivers/scsi/iscsi_tcp.h | 1 +
drivers/scsi/scsi_transport_iscsi.c | 17 +++---
include/scsi/scsi_transport_iscsi.h | 3 ++
5 files changed, 52 insertions(+), 26 deletions(-)
diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index 6865f62eb831..ca8de612d585 100644
--- a/drivers/infiniband/ulp/iser/iscsi_iser.c
+++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
@@ -593,20 +593,10 @@ static inline unsigned int iser_dif_prot_caps(int
prot_caps)
return ret;
}
-/**
- * iscsi_iser_session_create() - create an iscsi-iser session
- * @ep: iscsi end-point handle
- * @cmds_max: maximum commands in this session
- * @qdepth: session command queue depth
- * @initial_cmdsn: initiator command sequnce number
- *
- * Allocates and adds a scsi host, expose DIF supprot if
- * exists, and sets up an iscsi session.
- */
static struct iscsi_cls_session *
-iscsi_iser_session_create(struct iscsi_endpoint *ep,
+__iscsi_iser_session_create(struct iscsi_endpoint *ep,
uint16_t cmds_max, uint16_t qdepth,
- uint32_t initial_cmdsn)
+ uint32_t initial_cmdsn, struct net *net)
{
struct iscsi_cls_session *cls_session;
struct Scsi_Host *shost;
@@ -694,6 +684,32 @@ iscsi_iser_session_create(struct iscsi_endpoint *ep,
return NULL;
}
+/**
+ * iscsi_iser_session_create() - create an iscsi-iser session
+ * @ep: iscsi end-point handle
+ * @cmds_max: maximum commands in this session
+ * @qdepth: session command queue depth
+ * @initial_cmdsn: initiator command sequnce number
+ *
+ * Allocates and adds a scsi host, expose DIF supprot if
+ * exists, and sets up an iscsi session.
+ */
+static struct iscsi_cls_session *
+iscsi_iser_session_create(struct iscsi_endpoint *ep,
+ uint16_t cmds_max, uint16_t qdepth,
+ uint32_t initial_cmdsn) {
+ return __iscsi_iser_session_create(ep, cmds_max, qdepth,
+ initial_cmdsn, NULL);
+}
+
+static struct iscsi_cls_session *
+iscsi_iser_unbound_session_create(struct net *net,
+ uint16_t cmds_max, uint16_t qdepth,
+ uint32_t initial_cmdsn) {
+ return __iscsi_iser_session_create(NULL, cmds_max, qdepth,
+ initial_cmdsn, net);
+}
+
static int iscsi_iser_set_param(struct iscsi_cls_conn *cls_conn,
enum iscsi_param param, char *buf, int buflen)
{
@@ -983,6 +999,7 @@ static struct iscsi_transport iscsi_iser_transport = {
.caps = CAP_RECOVERY_L0 | CAP_MULTI_R2T |
CAP_TEXT_NEGO,
/* session management */
.create_session = iscsi_iser_session_create,
+ .create_unbound_session = iscsi_iser_unbound_session_create,
.destroy_session= iscsi_iser_session_destroy,
/* connection management */
.create_conn= iscsi_iser_conn_create,
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 171685011ad9..b78239f25073 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -922,7 +922,7 @@ iscsi_sw_tcp_conn_get_stats(struct iscsi_cls_conn *cls_conn,
}
static struct iscsi_cls_session
Re: [RFC PATCH 4/9] iscsi: make all iSCSI netlink multicast namespace aware
On 4/10/23 21:10, Chris Leech wrote: As discussed with Lee: you should tear down sessions related to this namespace from the pernet ->exit callback, otherwise you end up with session which can no longer been reached as the netlink socket is gone. These two follow on changes handle removing active sesions when the namespace exits. Tested with iscsi_tcp and seems to be working for me. Chris Leech (2): iscsi: make session and connection lists per-net iscsi: force destroy sesions when a network namespace exits drivers/scsi/scsi_transport_iscsi.c | 122 ++-- 1 file changed, 79 insertions(+), 43 deletions(-) Thanks a lot! That's precisely what I had been looking for. But you really shouldn't have mentioned iSCSI offloads; that was too large an opening to _not_ comment on :-) Cheers, Hannes -- Dr. Hannes ReineckeKernel Storage Architect h...@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman -- 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/f3c23291-2f77-4935-4e1c-a61cbe29241a%40suse.de.
Re: [PATCH 11/11] iscsi: force destroy sesions when a network namespace exits
On 4/10/23 21:10, Chris Leech wrote: The namespace is gone, so there is no userspace to clean up. Force close all the sessions. This should be enough for software transports, there's no implementation of migrating physical iSCSI hosts between network namespaces currently. Ah, you shouldn't have mentioned that. (Not quite sure how being namespace-aware relates to migration, though.) We should be checking/modifying the iSCSI offload drivers, too. But maybe with a later patch. Signed-off-by: Chris Leech --- drivers/scsi/scsi_transport_iscsi.c | 18 ++ 1 file changed, 18 insertions(+) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeKernel Storage Architect h...@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman -- 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/85458436-702f-2e38-c7cc-ff7329731eda%40suse.de.
Re: [PATCH 10/11] iscsi: make session and connection lists per-net
On 4/10/23 21:10, Chris Leech wrote: Eliminate the comparisions on list lookups, and it will make it easier to shut down session on net namespace exit in the next patch. Signed-off-by: Chris Leech --- drivers/scsi/scsi_transport_iscsi.c | 104 1 file changed, 61 insertions(+), 43 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeKernel Storage Architect h...@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman -- 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/0288a1cb-d2a0-6493-eae0-1d1b1fe9209c%40suse.de.
Re: [RFC PATCH 9/9] iscsi: filter flashnode sysfs by net namespace
On 2/8/23 18:40, Lee Duncan wrote: 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(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- 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/2f6cadce-3680-f80c-7016-5300e9b2ff9a%40suse.de.
Re: [RFC PATCH 8/9] iscsi: rename iscsi_bus_flash_* to iscsi_flash_*
On 2/8/23 18:40, Lee Duncan wrote: 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(-) Can be merged with the previous patch, but otherwise: Reviewed-by: Hannes Reinecke Cheers, Hannes -- 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/0c54c25f-2aab-27b6-864e-2942ead86d36%40suse.de.
Re: [RFC PATCH 7/9] iscsi: convert flashnode devices from bus to class
On 2/8/23 18:40, Lee Duncan wrote: 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(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- 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/81e3d1f1-26c4-0fd3-7c99-00de4d8d9f12%40suse.de.
Re: [RFC PATCH 6/9] iscsi: check net namespace for all iscsi lookup
On 2/8/23 18:40, Lee Duncan wrote: 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(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- 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/f6b53945-bbc2-f6b2-7d70-4f11849af5ce%40suse.de.
Re: [RFC PATCH 5/9] iscsi: set netns for iscsi_tcp hosts
On 2/8/23 18:40, Lee Duncan wrote:
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.
And indeed, I'd rather use the namespace from the iscsi netlink socket.
If you use the namespace from session creation you'd better hope that
this function is not called from a workqueue ...
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;
+}
+
See above if you can't reference the namespace for the netlink socket here.
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);
};
/*
Cheers,
Hannes
--
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/82eb95ac-2dca-7a7a-116a-2771c4551bab%40suse.de.
Re: [RFC PATCH 4/9] iscsi: make all iSCSI netlink multicast namespace aware
GFP_KERNEL);
} while (err < 0 && err != -ECONNREFUSED);
@@ -3818,7 +3840,8 @@ static int iscsi_logout_flashnode_sid(struct iscsi_transport *transport,
}
static int
-iscsi_get_host_stats(struct iscsi_transport *transport, struct nlmsghdr *nlh)
+iscsi_get_host_stats(struct net *net, struct iscsi_transport *transport,
+struct nlmsghdr *nlh)
{
struct iscsi_uevent *ev = nlmsg_data(nlh);
struct Scsi_Host *shost = NULL;
@@ -3878,8 +3901,8 @@ iscsi_get_host_stats(struct iscsi_transport *transport,
struct nlmsghdr *nlh)
skb_trim(skbhost_stats, NLMSG_ALIGN(actual_size));
nlhhost_stats->nlmsg_len = actual_size;
- err = iscsi_multicast_skb(skbhost_stats, ISCSI_NL_GRP_ISCSID,
- GFP_KERNEL);
+ err = iscsi_multicast_skb(net, skbhost_stats,
+ ISCSI_NL_GRP_ISCSID, GFP_KERNEL);
} while (err < 0 && err != -ECONNREFUSED);
exit_host_stats:
@@ -4001,7 +4024,8 @@ static int iscsi_if_transport_conn(struct iscsi_transport
*transport,
}
static int
-iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
+iscsi_if_recv_msg(struct net *net, struct sk_buff *skb,
+ struct nlmsghdr *nlh, uint32_t *group)
{
int err = 0;
u32 portid;
@@ -4096,7 +4120,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr
*nlh, uint32_t *group)
err = iscsi_if_transport_conn(transport, nlh);
break;
case ISCSI_UEVENT_GET_STATS:
- err = iscsi_if_get_stats(transport, nlh);
+ err = iscsi_if_get_stats(net, transport, nlh);
break;
case ISCSI_UEVENT_TRANSPORT_EP_CONNECT:
case ISCSI_UEVENT_TRANSPORT_EP_POLL:
@@ -4121,7 +4145,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr
*nlh, uint32_t *group)
err = iscsi_send_ping(transport, ev);
break;
case ISCSI_UEVENT_GET_CHAP:
- err = iscsi_get_chap(transport, nlh);
+ err = iscsi_get_chap(net, transport, nlh);
break;
case ISCSI_UEVENT_DELETE_CHAP:
err = iscsi_delete_chap(transport, ev);
@@ -4152,7 +4176,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr
*nlh, uint32_t *group)
nlmsg_attrlen(nlh, sizeof(*ev)));
break;
case ISCSI_UEVENT_GET_HOST_STATS:
- err = iscsi_get_host_stats(transport, nlh);
+ err = iscsi_get_host_stats(net, transport, nlh);
break;
default:
err = -ENOSYS;
@@ -4170,6 +4194,8 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr
*nlh, uint32_t *group)
static void
iscsi_if_rx(struct sk_buff *skb)
{
+ struct sock *sk = skb->sk;
+ struct net *net = sock_net(sk);
u32 portid = NETLINK_CB(skb).portid;
mutex_lock(_queue_mutex);
@@ -4192,7 +4218,7 @@ iscsi_if_rx(struct sk_buff *skb)
if (rlen > skb->len)
rlen = skb->len;
- err = iscsi_if_recv_msg(skb, nlh, );
+ err = iscsi_if_recv_msg(net, skb, nlh, );
if (err) {
ev->type = ISCSI_KEVENT_IF_ERROR;
ev->iferror = err;
@@ -4208,7 +4234,9 @@ iscsi_if_rx(struct sk_buff *skb)
break;
if (ev->type == ISCSI_UEVENT_GET_CHAP && !err)
break;
- err = iscsi_if_send_reply(portid, nlh->nlmsg_type,
+ if (ev->type == ISCSI_UEVENT_GET_HOST_STATS && !err)
+ break;
+ err = iscsi_if_send_reply(net, portid, nlh->nlmsg_type,
ev, sizeof(*ev));
if (err == -EAGAIN && --retries < 0) {
printk(KERN_WARNING "Send reply failed, error
%d\n", err);
As discussed with Lee: you should tear down sessions related to this
namespace from the pernet ->exit callback, otherwise you end up with
session which can no longer been reached as the netlink socket is gone.
Might be done in an additional patch, though.
If you do you can add:
Reviewed-by: Hannes Reinecke
to this patch.
Cheers,
Hannes
--
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/83de4002-6846-2f90-7848-ef477f0b0fe5%40suse.de.
Re: [RFC PATCH 3/9] iscsi: sysfs filtering by network namespace
On 2/8/23 18:40, Lee Duncan wrote: 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(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- 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/e71a718e-9d36-095a-9c7b-ea7761fe486a%40suse.de.
Re: [RFC PATCH 2/9] iscsi: associate endpoints with a host
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;
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)
Umm... doesn't this change the sysfs layout?
IE won't the endpoint node be moved under the
Re: [RFC PATCH 1/9] iscsi: create per-net iscsi netlink kernel sockets
On 2/8/23 18:40, Lee Duncan wrote: From: Lee Duncan Prepare iSCSI netlink to operate in multiple namespaces. Signed-off-by: Chris Leech Signed-off-by: Lee Duncan Reviewed-by: Hannes Reinecke Cheers, Hannes -- 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/b867f388-df15-df08-349e-4c80aabec5a7%40suse.de.
Re: [RFC 0/9] Make iscsid-kernel communications namespace-aware
On 2/8/23 18: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(-) Awesome work! Thanks for this! Comments to follow on the individual patches. Cheers, Hannes -- 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/bc73fcf1-d679-ec43-8235-b6342f78c1ba%40suse.de.
Re: [PATCH 24/24] osst: add a SPDX tag to osst.c
On 5/2/19 9:55 PM, Willem Riede wrote: On Thu, May 2, 2019 at 7:19 AM Hannes Reinecke <mailto:h...@suse.de>> wrote: On 5/2/19 2:53 PM, Christoph Hellwig wrote: > On Thu, May 02, 2019 at 08:06:38AM +0200, Hannes Reinecke wrote: >> On 5/1/19 6:14 PM, Christoph Hellwig wrote: >>> osst.c is the only osst file missing licensing information. Add a >>> GPLv2 tag for the default kernel license. >>> >>> Signed-off-by: Chriosstoph Hellwig mailto:h...@losst.de>> > > FYI, my s/st/osst/ on the commit message message up my signoff, this > should be: > > Signed-off-by: Christoph Hellwig mailto:h...@lst.de>> > Maybe it's time to kill osst.c for good ... Yes. I've been thinking about doing just that. The devices it supports are now thoroughly obsolete. The manufacturer has gone out of business. All my test drives have broken down over time, so I can't even test any changes any more. Just when I thought to reach out to you :-) Thing is, we've done numerous changes to the 'st' driver in the course of the years, most of which seem to have avoided osst :-( So what's your suggestion here? Just drop it completely? Or can we somehow fold the OnStream-specific things back into st.c? Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 24/24] osst: add a SPDX tag to osst.c
On 5/2/19 2:53 PM, Christoph Hellwig wrote: On Thu, May 02, 2019 at 08:06:38AM +0200, Hannes Reinecke wrote: On 5/1/19 6:14 PM, Christoph Hellwig wrote: osst.c is the only osst file missing licensing information. Add a GPLv2 tag for the default kernel license. Signed-off-by: Chriosstoph Hellwig FYI, my s/st/osst/ on the commit message message up my signoff, this should be: Signed-off-by: Christoph Hellwig Maybe it's time to kill osst.c for good ... Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 24/24] osst: add a SPDX tag to osst.c
On 5/1/19 6:14 PM, Christoph Hellwig wrote: osst.c is the only osst file missing licensing information. Add a GPLv2 tag for the default kernel license. Signed-off-by: Chriosstoph Hellwig --- drivers/scsi/osst.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/osst.c b/drivers/scsi/osst.c index be3c73ebbfde..fe4f0e7d6359 100644 --- a/drivers/scsi/osst.c +++ b/drivers/scsi/osst.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* SCSI Tape Driver for Linux version 1.1 and newer. See the accompanying file Documentation/scsi/st.txt for more information. Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 22/24] sr: add a SPDX tag to sr.c
On 5/1/19 6:14 PM, Christoph Hellwig wrote: sr.c is the only sr file missing licensing information. Add a GPLv2 tag for the default kernel license. Signed-off-by: Christoph Hellwig --- drivers/scsi/sr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c index 039c27c2d7b3..701d1e68d86e 100644 --- a/drivers/scsi/sr.c +++ b/drivers/scsi/sr.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * sr.c Copyright (C) 1992 David Giller * Copyright (C) 1993, 1994, 1995, 1999 Eric Youngdale Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 23/24] st: add a SPDX tag to st.c
On 5/1/19 6:14 PM, Christoph Hellwig wrote: st.c is the only st file missing licensing information. Add a GPLv2 tag for the default kernel license. Signed-off-by: Christoph Hellwig --- drivers/scsi/st.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c index 19c022e66d63..b814906af0a3 100644 --- a/drivers/scsi/st.c +++ b/drivers/scsi/st.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* SCSI Tape Driver for Linux version 1.1 and newer. See the accompanying file Documentation/scsi/st.txt for more information. Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 20/24] ses: switch to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2 SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/ses.c | 20 ++-- 1 file changed, 2 insertions(+), 18 deletions(-) diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c index 0fc39224ce1e..8afea5a1d3f0 100644 --- a/drivers/scsi/ses.c +++ b/drivers/scsi/ses.c @@ -1,25 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0 /* * SCSI Enclosure Services * * Copyright (C) 2008 James Bottomley - * -**- -** -** This program is free software; you can redistribute it and/or -** modify it under the terms of the GNU General Public License -** version 2 as published by the Free Software Foundation. -** -** This program is distributed in the hope that it will be useful, -** but WITHOUT ANY WARRANTY; without even the implied warranty of -** MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -** GNU General Public License for more details. -** -** You should have received a copy of the GNU General Public License -** along with this program; if not, write to the Free Software -** Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. -** -**- -*/ + */ #include #include Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 21/24] sg: switch to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2+ SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/sg.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c index d3f15319b9b3..bcdc28e5ede7 100644 --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * History: * Started: Aug 9 by Lawrence Foard (entr...@world.std.com), @@ -8,12 +9,6 @@ *Copyright (C) 1992 Lawrence Foard * Version 2 and 3 extensions to driver: *Copyright (C) 1998 - 2014 Douglas Gilbert - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2, or (at your option) - * any later version. - * */ static int sg_version_num = 30536; /* 2 digits for each component */ Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 18/24] sd: add a SPDX tag to sd.c
On 5/1/19 6:14 PM, Christoph Hellwig wrote: sd.c is the only sd file missing licensing information. Add a GPLv2 tag for the default kernel license. Signed-off-by: Christoph Hellwig --- drivers/scsi/sd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 2b2bc4b49d78..4852c2223359 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0 /* * sd.c Copyright (C) 1992 Drew Eckhardt * Copyright (C) 1993, 1994, 1995, 1999 Eric Youngdale Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 19/24] sd: switch remaining files to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2 SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/sd_dif.c | 16 +--- drivers/scsi/sd_zbc.c | 16 +--- 2 files changed, 2 insertions(+), 30 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 16/24] libsas: switch sas_ata.[ch] to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2+ SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/libsas/sas_ata.c | 16 +--- 1 file changed, 1 insertion(+), 15 deletions(-) diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c index 1ecca71df8b5..d9131746737e 100644 --- a/drivers/scsi/libsas/sas_ata.c +++ b/drivers/scsi/libsas/sas_ata.c @@ -1,24 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * Support for SATA devices on Serial Attached SCSI (SAS) controllers * * Copyright (C) 2006 IBM Corporation * * Written by: Darrick J. Wong , IBM Corporation - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of the - * License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 - * USA */ #include Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 17/24] libsas: switch remaining files to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2 SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/libsas/sas_discover.c | 18 +- drivers/scsi/libsas/sas_event.c | 18 +- drivers/scsi/libsas/sas_expander.c | 16 +--- drivers/scsi/libsas/sas_host_smp.c | 5 + drivers/scsi/libsas/sas_init.c | 19 +-- drivers/scsi/libsas/sas_internal.h | 19 +-- drivers/scsi/libsas/sas_phy.c | 18 +- drivers/scsi/libsas/sas_port.c | 18 +- drivers/scsi/libsas/sas_scsi_host.c | 19 +-- include/scsi/libsas.h | 19 +-- include/scsi/sas.h | 19 +-- include/scsi/sas_ata.h | 17 + 12 files changed, 12 insertions(+), 193 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 15/24] libsas: add a SPDX tag to sas_task.c
On 5/1/19 6:14 PM, Christoph Hellwig wrote: sas_task.c is the only libsas file missing licensing information. Add a GPLv2 tag for the default kernel license. Signed-off-by: Christoph Hellwig --- drivers/scsi/libsas/sas_task.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/libsas/sas_task.c b/drivers/scsi/libsas/sas_task.c index c3b9befad4e6..a46e8e4c0684 100644 --- a/drivers/scsi/libsas/sas_task.c +++ b/drivers/scsi/libsas/sas_task.c @@ -1,4 +1,4 @@ - +// SPDX-License-Identifier: GPL-2.0 #include "sas_internal.h" #include Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 14/24] libiscsi: switch to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2+ SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/libiscsi.c | 15 +-- drivers/scsi/libiscsi_tcp.c | 13 + include/scsi/iscsi_if.h | 13 + include/scsi/iscsi_proto.h| 13 + include/scsi/libiscsi.h | 15 +-- include/scsi/libiscsi_tcp.h | 13 + include/scsi/scsi_bsg_iscsi.h | 16 +--- 7 files changed, 7 insertions(+), 91 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 12/24] libfc: switch to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2 SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/libfc/fc_disc.c | 14 +- drivers/scsi/libfc/fc_elsct.c | 14 +- drivers/scsi/libfc/fc_exch.c | 14 +- drivers/scsi/libfc/fc_fcp.c | 14 +- drivers/scsi/libfc/fc_frame.c | 14 +- drivers/scsi/libfc/fc_libfc.c | 14 +- drivers/scsi/libfc/fc_libfc.h | 14 +- drivers/scsi/libfc/fc_lport.c | 14 +- drivers/scsi/libfc/fc_npiv.c | 14 +- drivers/scsi/libfc/fc_rport.c | 14 +- include/scsi/fc/fc_encaps.h | 14 +- include/scsi/fc/fc_fc2.h | 14 +- include/scsi/fc/fc_fcoe.h | 14 +- include/scsi/fc/fc_fcp.h | 14 +- include/scsi/fc/fc_fip.h | 14 +- include/scsi/fc/fc_ms.h | 17 +++-- include/scsi/libfc.h | 14 +- 17 files changed, 19 insertions(+), 222 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 13/24] libfcoe: switch to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2 SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/fcoe/fcoe.c | 14 +- drivers/scsi/fcoe/fcoe.h | 14 +- drivers/scsi/fcoe/fcoe_ctlr.c | 14 +- drivers/scsi/fcoe/fcoe_sysfs.c | 14 +- drivers/scsi/fcoe/fcoe_transport.c | 14 +- include/scsi/libfcoe.h | 14 +- 6 files changed, 6 insertions(+), 78 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 10/24] scsi_transport_srp: switch to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2+ SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/scsi_transport_srp.c | 16 +--- 1 file changed, 1 insertion(+), 15 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 11/24] libfc: remove duplicate GPL boilerplate text
On 5/1/19 6:14 PM, Christoph Hellwig wrote: The libfc uapi headers already have proper SPDX tags, remove the duplicate boilerplate text. Signed-off-by: Christoph Hellwig --- include/uapi/scsi/fc/fc_els.h | 13 - include/uapi/scsi/fc/fc_fs.h | 13 - include/uapi/scsi/fc/fc_gs.h | 13 - include/uapi/scsi/fc/fc_ns.h | 13 - 4 files changed, 52 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 08/24] scsi_transport_sas: switch to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2 SPDX tag instead of a free form blurb. Signed-off-by: Christoph Hellwig --- drivers/scsi/scsi_transport_sas.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 09/24] scsi_transport_spi: switch to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2+ SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/scsi_transport_spi.c | 15 +-- include/scsi/scsi_transport_spi.h | 15 +-- 2 files changed, 2 insertions(+), 28 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 07/24] scsi_transport_iscsi: switch to SPDX tags
On 5/1/19 6:14 PM, Christoph Hellwig wrote: Use the the GPLv2+ SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/scsi_transport_iscsi.c | 15 +-- include/scsi/scsi_transport_iscsi.h | 15 +-- 2 files changed, 2 insertions(+), 28 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 06/24] scsi_transport_fc: switch to SPDX tags
On 5/1/19 6:13 PM, Christoph Hellwig wrote: Use the the GPLv2+ SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/scsi_transport_fc.c | 18 +- include/scsi/scsi_transport_fc.h | 18 +- 2 files changed, 2 insertions(+), 34 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 05/24] scsi_transport_fc: remove duplicate GPL boilerplate text
On 5/1/19 6:13 PM, Christoph Hellwig wrote: The FC transport class uapi headers already have proper SPDX tags, remove the duplicate boilerplate text. Signed-off-by: Christoph Hellwig --- include/uapi/scsi/scsi_bsg_fc.h | 15 --- include/uapi/scsi/scsi_netlink_fc.h | 15 --- 2 files changed, 30 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 04/24] scsi_transport.h: switch to SPDX tags
On 5/1/19 6:13 PM, Christoph Hellwig wrote: Use the the GPLv2+ SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- include/scsi/scsi_transport.h | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 03/24] scsi_netlink: remove duplicate GPL boilerplate text
On 5/1/19 6:13 PM, Christoph Hellwig wrote: The SCSI netlink uapi header already has a proper SPDX tag, remove the duplicate boilerplate text. Signed-off-by: Christoph Hellwig --- include/uapi/scsi/scsi_netlink.h | 15 --- 1 file changed, 15 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 02/24] scsi: switch the remaining scsi midlayer files to use SPDX tags
On 5/1/19 6:13 PM, Christoph Hellwig wrote: Use the GPLv2 SPDX tag instead of verbose boilerplate text. Signed-off-by: Christoph Hellwig --- drivers/scsi/scsi_logging.c | 3 +-- drivers/scsi/scsi_sysctl.c | 2 +- drivers/scsi/scsi_trace.c | 14 +- 3 files changed, 3 insertions(+), 16 deletions(-) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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 01/24] scsi: add SPDX tags to scsi midlayer files missing licensing information
On 5/1/19 6:13 PM, Christoph Hellwig wrote: Add the default kernel GPLv2 annotation to SCSI midlayer files missing any licensing information. Signed-off-by: Christoph Hellwig --- drivers/scsi/hosts.c| 1 + drivers/scsi/scsi.c | 1 + drivers/scsi/scsi_debugfs.h | 1 + drivers/scsi/scsi_error.c | 1 + drivers/scsi/scsi_ioctl.c | 1 + drivers/scsi/scsi_lib.c | 1 + drivers/scsi/scsi_pm.c | 1 + drivers/scsi/scsi_sysfs.c | 1 + 8 files changed, 8 insertions(+) Reviewed-by: Hannes Reinecke Cheers, Hannes -- Dr. Hannes ReineckeTeamlead Storage & Networking h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg) -- 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: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0
On 12/24/2016 11:07 AM, Christoph Hellwig wrote: On Fri, Dec 23, 2016 at 11:42:45AM -0800, Linus Torvalds wrote: Ugh. This patch is nasty. It's the same SCSI has done for ages - except that is uses a separate kmalloc for the sense buffer. I think we should just fix blk_execute_rq() instead. As you found out below it's not just blk_execute_rq, it's the whole architecture of the BLOCK_PC code, which expects a caller provided sense buffer. But with the way blk-mq allocates request structures we can actually fix it, but I first need to extent the way it allows drivers to allocate private data to the old request code. I've actually already implemented that for SCSI long time ago, and have started to life it to the block layer. Would be cool to have a generic sense buffer. I always found it slightly odd, pretending that 'struct request' is protocol-agnostic and refusing to add a sense data pointer, but at the same time having a field 'sense_len' (which gives the length of what exactly?). Christoph, do you have a pointer to your patchset? Not that I'll be able to do any meaningful work until next year, but having a look would be nice. Just to get a feeling where you want to head to; I might be able to work on this start of January. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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
On 11/21/2016 06:41 PM, Lee Duncan wrote:
>
>> On Nov 21, 2016, at 6:14 AM, Hannes Reinecke <h...@suse.de
>> <mailto:h...@suse.de>> 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.
>
Yeah, you are correct.
Please fix it up while you're at it.
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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
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
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
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.
>From 74a63d90b9fc4ce0c4c329b0562bb1358804385c Mon Sep 17 00:00:00 2001
From: Hannes Reinecke <h...@suse.de>
Date: Mon, 21 Nov 2016 10:07:39 +0100
Subject: [PATCH] Use timeout when waiting for responses from iscsid
The server might already been terminated when iscsiadm tries to
send a request to it, hence we might be waiting forever for a reply.
With this patchset we're waiting at most one minute before giving up,
avoiding a hang in iscsiadm.
Signed-off-by: Hannes Reinecke <h...@suse.com>
---
usr/config.h | 1 +
usr/discovery.c| 16
usr/host.c | 2 +-
usr/iscsi_sysfs.c | 1 +
usr/iscsiadm.c | 11 ++-
usr/iscsid.c | 2 +-
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, 81 insertions(+), 41 deletions(-)
diff --git a/usr/config.h b/usr/config.h
index 2e36a0a..a464cfd 100644
--- a/usr/config.h
+++ b/usr/config.h
@@ -316,6 +316,7 @@ typedef struct discovery_rec {
discovery_type_e type;
char address[NI_MAXHOST];
int port;
+ int iscsid_req_tmo;
union {
struct iscsi_sendtargets_config sendtargets;
struct iscsi_slp_config slp;
diff --git a/usr/discovery.c b/usr/discovery.c
index ee26a90..9e17f07 100644
--- a/usr/discovery.c
+++ b/usr/discovery.c
@@ -66,7 +66,7 @@ static char initiator_name[TARGET_NAME_MAX
Re: [PATCH 1/3] scsi_transport_iscsi: Add stats support for iscsi host
_ERR;
>> +else if (attr == _attr_host_session_fails.attr)
>> +param = ISCSI_HOST_PARAM_SESSION_FAILS;
>> else {
>> WARN_ONCE(1, "Invalid host attr");
>> return 0;
>> diff --git a/include/scsi/iscsi_if.h b/include/scsi/iscsi_if.h
>> index d66c070..d6a3909 100644
>> --- a/include/scsi/iscsi_if.h
>> +++ b/include/scsi/iscsi_if.h
>> @@ -632,6 +632,18 @@ enum iscsi_host_param {
>> ISCSI_HOST_PARAM_IPADDRESS,
>> ISCSI_HOST_PARAM_PORT_STATE,
>> ISCSI_HOST_PARAM_PORT_SPEED,
>> +ISCSI_HOST_PARAM_LOGIN_ACCEPT_RSPS,
>> +ISCSI_HOST_PARAM_LOGIN_OTHER_FAILS,
>> +ISCSI_HOST_PARAM_LOGIN_AUTHENTICATION_FAILS,
>> +ISCSI_HOST_PARAM_LOGIN_AUTHORIZATION_FAILS,
>> +ISCSI_HOST_PARAM_LOGIN_NEGOTIATION_FAILS,
>> +ISCSI_HOST_PARAM_LOGIN_REDIRECT_RSPS,
>> +ISCSI_HOST_PARAM_LOGOUT_NORMAL_RSPS,
>> +ISCSI_HOST_PARAM_LOGOUT_OTHER_RSPS,
>> +ISCSI_HOST_PARAM_DIGEST_ERR,
>> +ISCSI_HOST_PARAM_TIMEOUT_ERR,
>> +ISCSI_HOST_PARAM_FORMAT_ERR,
>> +ISCSI_HOST_PARAM_SESSION_FAILS,
>> ISCSI_HOST_PARAM_MAX,
>> };
>>
>> @@ -819,6 +831,18 @@ struct iscsi_stats {
>> /* errors */
>> uint32_t digest_err;
>> uint32_t timeout_err;
>> +uint32_t format_err;
>> +uint32_t session_fails;
>> +
>> +/* login/logout stats */
>> +uint32_t login_accept_rsps;
>> +uint32_t login_other_fails;
>> +uint32_t login_authentication_fails;
>> +uint32_t login_authorization_fails;
>> +uint32_t login_negotiation_fails;
>> +uint32_t login_redirect_rsps;
>> +uint32_t logout_normal_rsps;
>> +uint32_t logout_other_rsps;
>>
>
> I do not think we can add new fields here because this is passed between
> the kernel and userspace.
>
> Also, lets either go with the get stats nl type of approach or say we
> are depreciating that and going with sysfs now and the future. Not a mix
> based on who is submitting patches.
>
> I can see why the get stats approach is nasty, because it is difficult
> to extend. If we want to go sysfs based approach then we should probably
> make it more like the other transports where there is a stats dir and a
> reset admin file.
>
> Lee and Chris should probably decide how to proceed.
>
Hmm.
For these kind of things I wonder whether debugfs isn't the correct way
of doing. Thing is, sysfs is complicated enough already, and is
considered a _stable_ kernel API.
So everytime you add fields there you have to fight it out with
upstream. It becomes especially bad when you have to _change_ fields, or
even remove them.
>From my POV statistics are unstable, as not every device/implementation
might be able to deliver the same set. Plus I really would like to
reserve the right to change them as needed; this patchset is the best
example for it.
Hence I would not be using sysfs for it, but rather debugfs or something
like that.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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] remove sysfs attr_list
On 03/01/2016 04:27 PM, Ferenc Wágner wrote: > Hannes Reinecke <h...@suse.de> writes: > >> On 02/29/2016 10:58 PM, Bart Van Assche wrote: >> >>> On 02/28/16 23:59, Hannes Reinecke wrote: >>> >>>> libudev has a _massive_ static memory footprint >>>> (Kay doesn't believe in memory allocation). >>>> So when using libudev you might end up having a really large memory >>>> footprint due to all the on-stack allocations in there. >>>> Be especially careful when attempting to use pthreads; debugging stack >>>> overflow in pthreads is no fun whatsoever. >>> >>> That's exactly the reason why I never allocate large data structures on >>> the stack in applications I write myself and why I use dynamic memory >>> allocation for large data structures. To make sure that such large stack >>> allocations get detected I set the stack size to a low value: >>> >>> pthread_attr_t attr; >>> pthread_attr_init(); >>> pthread_attr_setstacksize(, PTHREAD_STACK_MIN); >>> pthread_create(..., , ..., ...); >> >> Oh, I don't need to detect them. >> I know exactly where they are. But precisely that is a design goal of >> the libudev code, so any patches trying to fix that up will be discarded >> out-of-hand :-( > > Do you mean that it's a design goal to avoid dynamic allocations in the > libudev code? What's the rationale for that? Avoiding leaks at all costs? > (Sorry for the offtopic, but I wonder...) > Hey, don't ask me. _I_ didn't write that code. Kay Sievers appears to like it, so better ask him. (I would think the idea is that you don't need to do memory allocations, which might fail after all) Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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] remove sysfs attr_list
On 02/29/2016 10:58 PM, Bart Van Assche wrote: > On 02/28/16 23:59, Hannes Reinecke wrote: >> libudev has a _massive_ static memory footprint >> (Kay doesn't believe in memory allocation). >> So when using libudev you might end up having a really large memory >> footprint due to all the on-stack allocations in there. >> Be especially careful when attempting to use pthreads; debugging stack >> overflow in pthreads is no fun whatsoever. > > That's exactly the reason why I never allocate large data structures on > the stack in applications I write myself and why I use dynamic memory > allocation for large data structures. To make sure that such large stack > allocations get detected I set the stack size to a low value: > > pthread_attr_t attr; > pthread_attr_init(); > pthread_attr_setstacksize(, PTHREAD_STACK_MIN); > pthread_create(..., , ..., ...); > Oh, I don't need to detect them. I know exactly where they are. But precisely that is a design goal of the libudev code, so any patches trying to fix that up will be discarded out-of-hand :-( Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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: DEFINE_IDA causing memory leaks? (was Re: [PATCH 1/2] virtio: fix memory leak of virtio ida cache layers)
On 09/17/2015 07:33 AM, Michael S. Tsirkin wrote: > On Wed, Sep 16, 2015 at 07:29:17PM -0500, Suman Anna wrote: >> The virtio core uses a static ida named virtio_index_ida for >> assigning index numbers to virtio devices during registration. >> The ida core may allocate some internal idr cache layers and >> an ida bitmap upon any ida allocation, and all these layers are >> truely freed only upon the ida destruction. The virtio_index_ida >> is not destroyed at present, leading to a memory leak when using >> the virtio core as a module and atleast one virtio device is >> registered and unregistered. >> >> Fix this by invoking ida_destroy() in the virtio core module >> exit. >> >> Cc: "Michael S. Tsirkin" <m...@redhat.com> >> Signed-off-by: Suman Anna <s-a...@ti.com> > > Interesting. > Will the same apply to e.g. sd_index_ida in drivers/scsi/sd.c > or iscsi_sess_ida in drivers/scsi/scsi_transport_iscsi.c? > > If no, why not? > > One doesn't generally expect to have to free global variables. > Maybe we should forbid DEFINE_IDA in modules? > > James, could you comment on this please? > Well, looking at the code 'ida_destroy' only need to be called if you want/need to do a general cleanup. It shouldn't be required if you do correct reference counting on your objects, and call idr_remove() on each of them. Unless I'm misreading something. Seems like a topic for KS; Johannes had a larger patchset recently to clean up idr, which run into very much the same issues. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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.
[PATCH] firmware: ACPI iBFT firmware support on EFI machines
The iBFT firmware tables can also be specified via ACPI tables when using EFI firmware. The 'iscsi_ibft_find' module is only for legacy X86 BIOS, so it needs to be skipped for all other architectures. Signed-off-by: Hannes Reinecke h...@suse.de --- drivers/firmware/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index 6517132..79204b2 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -124,7 +124,7 @@ config ISCSI_IBFT_FIND config ISCSI_IBFT tristate iSCSI Boot Firmware Table Attributes module select ISCSI_BOOT_SYSFS - depends on ISCSI_IBFT_FIND SCSI SCSI_LOWLEVEL + depends on (ISCSI_IBFT_FIND || ACPI) SCSI SCSI_LOWLEVEL default n help This option enables support for detection and exposing of iSCSI -- 1.8.5.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 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: [RFC PATCH 0/4] Make iSCSI network namespace aware
On 05/20/2015 08:45 PM, Andy Grover wrote: On 05/13/2015 03:12 PM, Chris Leech wrote: 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. Seems like a good direction, to me. What would be the extent of the userspace (open-iscsi) changes needed to go along with this? What I would like to see is to split off iscsid to have one instance/process per session. With that we could trivially run open-iscsi in containers and stufflike; currently it'll be hard as there really is only one iscsid expected to be running in a system. Cheers, Hannes -- Dr. Hannes ReineckezSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- 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: [LSF/MM TOPIC] iSCSI MQ adoption via MCS discussion
On 01/07/2015 05:25 PM, Sagi Grimberg wrote: Hi everyone, Now that scsi-mq is fully included, we need an iSCSI initiator that would use it to achieve scalable performance. The need is even greater for iSCSI offload devices and transports that support multiple HW queues. As iSER maintainer I'd like to discuss the way we would choose to implement that in iSCSI. My measurements show that iSER initiator can scale up to ~2.1M IOPs with multiple sessions but only ~630K IOPs with a single session where the most significant bottleneck the (single) core processing completions. In the existing single connection per session model, given that command ordering must be preserved session-wide, we end up in a serial command execution over a single connection which is basically a single queue model. The best fit seems to be plugging iSCSI MCS as a multi-queued scsi LLDD. In this model, a hardware context will have a 1x1 mapping with an iSCSI connection (TCP socket or a HW queue). iSCSI MCS and it's role in the presence of dm-multipath layer was discussed several times in the past decade(s). The basic need for MCS is implementing a multi-queue data path, so perhaps we may want to avoid doing any type link aggregation or load balancing to not overlap dm-multipath. For example we can implement ERL=0 (which is basically the scsi-mq ERL) and/or restrict a session to a single portal. As I see it, the todo's are: 1. Getting MCS to work (kernel + user-space) with ERL=0 and a round-robin connection selection (per scsi command execution). 2. Plug into scsi-mq - exposing num_connections as nr_hw_queues and using blk-mq based queue (conn) selection. 3. Rework iSCSI core locking scheme to avoid session-wide locking as much as possible. 4. Use blk-mq pre-allocation and tagging facilities. I've recently started looking into this. I would like the community to agree (or debate) on this scheme and also talk about implementation with anyone who is also interested in this. Yes, that's a really good topic. I've pondered implementing MC/S for iscsi/TCP but then I've figured my network implementation knowledge doesn't spread that far. So yeah, a discussion here would be good. Mike? Any comments? Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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: [PATCH] Allow modifications for iface.gateway and iface.subnet_mask
On 02/01/2014 06:37 AM, Mike Christie wrote:
On 1/29/14 4:19 AM, Hannes Reinecke wrote:
For proper operations we need to set gateway and subnet_mask
of the individual interfaces. Not every target is connected
to the local network.
Signed-off-by: Hannes Reinecke h...@suse.de
---
usr/idbm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/usr/idbm.c b/usr/idbm.c
index 1ade099..9f3e567 100644
--- a/usr/idbm.c
+++ b/usr/idbm.c
@@ -262,6 +262,8 @@ idbm_recinfo_node(node_rec_t *r, recinfo_t *ri)
__recinfo_str(IFACE_IPADDR, ri, r, iface.ipaddress, IDBM_SHOW,
num, 1);
__recinfo_str(IFACE_ISCSINAME, ri, r, iface.name, IDBM_SHOW,
num, 1);
__recinfo_str(IFACE_NETNAME, ri, r, iface.netdev, IDBM_SHOW,
num, 1);
+__recinfo_str(IFACE_GATEWAY, ri, r, iface.gateway, IDBM_SHOW,
num, 1);
+__recinfo_str(IFACE_SUBNET_MASK, ri, r, iface.subnet_mask,
IDBM_SHOW, num, 1);
/*
* svn 780 compat: older versions used node.transport_name and
* rec-transport_name
Is this still needed? A little before above we have
iface_type = iface_get_iptype(r-iface);
which should be returning ISCSI_IFACE_TYPE_IPV4. Then a little further
from the code your patch added we have:
if (iface_type == ISCSI_IFACE_TYPE_IPV4) {
__recinfo_str(IFACE_BOOT_PROTO, ri, r, iface.bootproto,
IDBM_SHOW, num, 1);
__recinfo_str(IFACE_SUBNET_MASK, ri, r, iface.subnet_mask,
IDBM_SHOW, num, 1);
__recinfo_str(IFACE_GATEWAY, ri, r, iface.gateway,
IDBM_SHOW,
num, 1);
Right, so we can drop this. Thanks for the pointer.
(I'm currently flushing our SUSE-specific patches, which for some reason
we never managed to send upstream. So I'm not surprised that
this patch is obsolete.)
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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/groups/opt_out.
[PATCH] Allow modifications for iface.gateway and iface.subnet_mask
For proper operations we need to set gateway and subnet_mask of the individual interfaces. Not every target is connected to the local network. Signed-off-by: Hannes Reinecke h...@suse.de --- usr/idbm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/usr/idbm.c b/usr/idbm.c index 1ade099..9f3e567 100644 --- a/usr/idbm.c +++ b/usr/idbm.c @@ -262,6 +262,8 @@ idbm_recinfo_node(node_rec_t *r, recinfo_t *ri) __recinfo_str(IFACE_IPADDR, ri, r, iface.ipaddress, IDBM_SHOW, num, 1); __recinfo_str(IFACE_ISCSINAME, ri, r, iface.name, IDBM_SHOW, num, 1); __recinfo_str(IFACE_NETNAME, ri, r, iface.netdev, IDBM_SHOW, num, 1); + __recinfo_str(IFACE_GATEWAY, ri, r, iface.gateway, IDBM_SHOW, num, 1); + __recinfo_str(IFACE_SUBNET_MASK, ri, r, iface.subnet_mask, IDBM_SHOW, num, 1); /* * svn 780 compat: older versions used node.transport_name and * rec-transport_name -- 1.8.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 http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/groups/opt_out.
[PATCH] Add missing DESTDIR
From: Lee Duncan ldun...@suse.com Several Makefile targets are missing DESTDIR, making it hard for packagers. Signed-off-by: Lee Duncan ldun...@suse.com Signed-off-by: Hannes Reinecke h...@suse.de --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 88b3529..79bad84 100644 --- a/Makefile +++ b/Makefile @@ -124,7 +124,7 @@ install_iface: $(IFACEFILES) $(INSTALL) -m 644 $^ $(DESTDIR)$(etcdir)/iscsi/ifaces install_etc: $(ETCFILES) - if [ ! -f /etc/iscsi/iscsid.conf ]; then \ + if [ ! -f $(DESTDIR)/etc/iscsi/iscsid.conf ]; then \ $(INSTALL) -d $(DESTDIR)$(etcdir)/iscsi ; \ $(INSTALL) -m 644 $^ $(DESTDIR)$(etcdir)/iscsi ; \ fi @@ -137,11 +137,11 @@ install_kernel: $(MAKE) -C kernel install_kernel install_iname: - if [ ! -f /etc/iscsi/initiatorname.iscsi ]; then \ + if [ ! -f $(DESTDIR)/etc/iscsi/initiatorname.iscsi ]; then \ echo InitiatorName=`$(DESTDIR)/sbin/iscsi-iname` $(DESTDIR)/etc/iscsi/initiatorname.iscsi ; \ echo *** ; \ echo Setting InitiatorName to `cat $(DESTDIR)/etc/iscsi/initiatorname.iscsi` ; \ - echo To override edit /etc/iscsi/initiatorname.iscsi ; \ + echo To override edit $(DESTDIR)/etc/iscsi/initiatorname.iscsi ; \ echo *** ; \ fi -- 1.8.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 http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/groups/opt_out.
Re: [PATCHv2 0/3] iscsiuio: Update autoconf
On 01/29/2014 07:27 PM, Eddie Wai wrote: The patchset works great on my system. Forcing an autoreconf and untrack all autogen files makes sense. Thanks for the work. Although I would be more inclined to put all .gitignore entries into a single .gitignore file in the trunk, separating them out is fine too. That's what I've tried, but somehow git would like it. Hence the split. There's actually an error in the autoconf files, which I discovered later during testing; in iscsiuio/src/uip/Makefile.am the statement lib_iscsi_uip_a_CFLAGS = is missing an $(AM_CFLAGS). Should I send an incremental patch or re-do the patchset? Cheers, Hannes -- 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/groups/opt_out.
Re: Multipath or not ?
On 03/12/2013 11:30 PM, Mike Christie wrote: On 03/12/2013 08:11 AM, Guillaume wrote: Hello Mike On 12 mar, 02:54, Mike Christie micha...@cs.wisc.edu wrote: On 03/09/2013 05:58 AM, Guillaume wrote: Hello, I have a virtual tape library and a iscsi SAN. All have multiple ethernet interfaces, This will ressult in multiples sessions to the targets.So I wonder if I must use dm-multipath or not ? Does the current Does the device show up as a tape device or a block device? The VTL device emulates robotics, LTO cartridges and LTO5 tape drives. The SAN is a block device. Are you using SCST or TGT or LIO for this? iscsi layer handle the multiple paths to an iqn or not ? Another question about the output of iscsiadm -m session : the lines of output begins by @IP:3260,n where n is an integer. Is this number a priority level in some way, or does it only distinguish multiple sessions to the same iqn ? It is the iSCSI target portal group number. It is assigned by the target. You can use it to group portals together. If the initiator and target supports MC/s you could then do a iSCSI level multipathing called MC/s over portals with the same target portal group number. open-iscsi does not support MC/s So what I understand is that I must use md-multipath to handle the Use dm-multipath. md-multipath is older and does not have as many features. Be _very_ cautious when using multipath on tapes. Tapes rely on precise I/O sequencing, but multipath only guarantees sequential I/O _submission_ at the initiator side. If multipath decides to requeue I/O to a different path because one path is blocked your tape is hosed. I'm not saying it cannot be handled, I'm just saying we haven't tested this properly. And certainly didn't implement any precautions to avoid this. But this would be best discussed on the dm-devel list. Cheers, Hannes -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [PATCH] Do not run configure for open-isns on every build
On 10/11/2011 05:05 AM, Mike Christie wrote: On 10/07/2011 09:09 AM, Hannes Reinecke wrote: We only need to run configure in open-isns if either the configure script or Makefile.in has changed. Otherwise it's perfectly okay just to call a plain 'make' here. Signed-off-by: Hannes Reineckeh...@suse.de diff --git a/Makefile b/Makefile index 8dd64c7..de7ef65 100644 --- a/Makefile +++ b/Makefile @@ -29,8 +29,8 @@ OPTFLAGS ?= -O2 -g all: user -user: ; - cd utils/open-isns; ./configure CFLAGS=$(OPTFLAGS) --with-security=no; $(MAKE) I did not have the optflags patch so we just had: -user: ; - cd utils/open-isns; ./configure --with-security=no; $(MAKE) Let me know if you have sent a optflags patch and I have missed it. Thanks. Ah, no. OPTFLAGS is for our build system (which insists on passing in it's own set of flags). I'll be pushing out a patch here. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
[PATCH] Do not run configure for open-isns on every build
We only need to run configure in open-isns if either the configure script or Makefile.in has changed. Otherwise it's perfectly okay just to call a plain 'make' here. Signed-off-by: Hannes Reinecke h...@suse.de diff --git a/Makefile b/Makefile index 8dd64c7..de7ef65 100644 --- a/Makefile +++ b/Makefile @@ -29,8 +29,8 @@ OPTFLAGS ?= -O2 -g all: user -user: ; - cd utils/open-isns; ./configure CFLAGS=$(OPTFLAGS) --with-security=no; $(MAKE) +user: utils/open-isns/Makefile + $(MAKE) -C utils/open-isns $(MAKE) -C utils/sysdeps $(MAKE) -C utils/fwparam_ibft $(MAKE) -C usr @@ -44,6 +44,9 @@ user: ; @echo @echo Read README file for detailed information. +utils/open-isns/Makefile: utils/open-isns/configure utils/open-isns/Makefile.in + cd utils/open-isns; ./configure CFLAGS=$(OPTFLAGS) --with-security=no + kernel: force $(MAKE) -C kernel @echo Kernel Compilation complete Output file -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: iscsi_sysfs_read_iface
On 07/26/2011 09:44 PM, Mike Christie wrote:
On 07/26/2011 01:38 AM, Hannes Reinecke wrote:
Hi Eddie,
you beat me to it ...
On 07/26/2011 02:28 AM, Eddie Wai wrote:
Hello Mike,
The following snippet from the 39d4ceb04f051c208ae7509d268a3871ffa194c5
commit is preventing bnx2i from being able to offload when connecting
through the iscsi_sysfs_get_hostinfo_by_host_no code path where the
session argument == NULL. The initiatorname sysfs inquiry failed but
this is expected since it does not exist in the iscsi_host for bnx2i.
Perhaps the error return code should only be propagated upward when
session != NULL specifically for hbas like qla4xxx?
Thanks,
Eddie
- 8 - 8 -
@@ -527,7 +528,10 @@ static int iscsi_sysfs_read_iface(struct iface_rec
*iface, int host_no,
iface_str(iface));
}
}
- return ret;
+ if (ret)
+ return ISCSI_ERR_SYSFS_LOOKUP;
+ else
+ return 0;
}
- 8 - 8 -
Actually, this is the patch I have:
diff --git a/usr/iscsi_sysfs.c b/usr/iscsi_sysfs.c
index e82fe80..145816d 100644
--- a/usr/iscsi_sysfs.c
+++ b/usr/iscsi_sysfs.c
@@ -489,7 +489,7 @@ static int iscsi_sysfs_read_iface(struct iface_rec
*iface, int host_no,
if (ret) {
ret = sysfs_get_str(id, ISCSI_HOST_SUBSYS, initiatorname,
iface-iname, sizeof(iface-iname));
- if (ret)
+ if (ret) {
/*
* default iname is picked up later from
* initiatorname.iscsi if software/partial-offload.
@@ -499,6 +499,8 @@ static int iscsi_sysfs_read_iface(struct iface_rec
*iface, int host_no,
*/
log_debug(7, Could not read initiatorname for
host%d\n, host_no);
+ ret = 0;
+ }
}
/*
(Well, of course it got line-wrapped, but should get you the idea).
I'll be sending the proper patch to the mailing-list shortly.
But yes, that is a real issue.
Yeah, this is right. That is the behavior we had before. I can just fix
this up and merge it if there were no other changes needed.
Not in this area, no.
I've got some minor patches to the SUSE init script but they still
need further testing.
And actually I'm working on an 'iscsi_offload' scripts which
configures the interface definitions for the various offload
engines. If there is enough interest maybe we should include it in
the open-iscsi tarball.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: iscsi_sysfs_read_iface
Hi Eddie,
you beat me to it ...
On 07/26/2011 02:28 AM, Eddie Wai wrote:
Hello Mike,
The following snippet from the 39d4ceb04f051c208ae7509d268a3871ffa194c5
commit is preventing bnx2i from being able to offload when connecting
through the iscsi_sysfs_get_hostinfo_by_host_no code path where the
session argument == NULL. The initiatorname sysfs inquiry failed but
this is expected since it does not exist in the iscsi_host for bnx2i.
Perhaps the error return code should only be propagated upward when
session != NULL specifically for hbas like qla4xxx?
Thanks,
Eddie
- 8 - 8 -
@@ -527,7 +528,10 @@ static int iscsi_sysfs_read_iface(struct iface_rec
*iface, int host_no,
iface_str(iface));
}
}
- return ret;
+ if (ret)
+ return ISCSI_ERR_SYSFS_LOOKUP;
+ else
+ return 0;
}
- 8 - 8 -
Actually, this is the patch I have:
diff --git a/usr/iscsi_sysfs.c b/usr/iscsi_sysfs.c
index e82fe80..145816d 100644
--- a/usr/iscsi_sysfs.c
+++ b/usr/iscsi_sysfs.c
@@ -489,7 +489,7 @@ static int iscsi_sysfs_read_iface(struct
iface_rec *iface, int host_no,
if (ret) {
ret = sysfs_get_str(id, ISCSI_HOST_SUBSYS,
initiatorname,
iface-iname,
sizeof(iface-iname));
- if (ret)
+ if (ret) {
/*
* default iname is picked up later from
* initiatorname.iscsi if
software/partial-offload.
@@ -499,6 +499,8 @@ static int iscsi_sysfs_read_iface(struct
iface_rec *iface, int host_no,
*/
log_debug(7, Could not read initiatorname
for
host%d\n, host_no);
+ ret = 0;
+ }
}
/*
(Well, of course it got line-wrapped, but should get you the idea).
I'll be sending the proper patch to the mailing-list shortly.
But yes, that is a real issue.
Independent on any bnx2i; any offloading engine _not_ listing the
initiatorname as a host attribute will fail.
Not nice.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 4/8] Keep startup mode in sync when specified in config file
On 06/28/2011 06:44 AM, Mike Christie wrote:
On 06/21/2011 04:23 AM, Hannes Reinecke wrote:
When the startup mode has been specified in iscsid.conf it
needs to be kept in sync for both settings, 'node.startup'
and 'node.conn[0].startup'.
References: bnc#458142
Signed-off-by: Hannes Reineckeh...@suse.de
---
usr/idbm.c | 25 -
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/usr/idbm.c b/usr/idbm.c
index a73b410..1f01535 100644
--- a/usr/idbm.c
+++ b/usr/idbm.c
@@ -598,6 +598,8 @@ void idbm_recinfo_config(recinfo_t *info, FILE *f)
char name[NAME_MAXVAL];
char value[VALUE_MAXVAL];
char *line, *nl, buffer[2048];
+ char *node_startup_value = NULL;
+ char *conn_startup_value = NULL;
int line_number = 0;
int c = 0, i;
@@ -656,8 +658,29 @@ void idbm_recinfo_config(recinfo_t *info, FILE *f)
}
*(value+i) = 0;
- idbm_rec_update_param(info, name, value, line_number);
+ if (!strcmp(name, node.startup)) {
+ node_startup_value = strdup(value);
+ }
+ if (!strcmp(name, node.conn[0].startup)) {
+ conn_startup_value = strdup(value);
+ }
+ (void)idbm_rec_update_param(info, name, value, line_number);
} while (line);
+ /*
+* Compat hack:
+* Keep node.startup and node.conn[0].startup in sync even
+* if only one of those has been specified in the config file.
+*/
+ if (node_startup_value !conn_startup_value) {
+ (void)idbm_rec_update_param(info, node.conn[0].startup,
+ node_startup_value, -1);
+ free(node_startup_value);
+ }
+ if (conn_startup_value !node_startup_value) {
+ (void)idbm_rec_update_param(info, node.startup,
+ conn_startup_value, -1);
+ free(conn_startup_value);
+ }
}
I think this is leaking memory.
If both the conn and node startup are set in the record then we leak.
They are both present in the record by default.
Also I think there is a possible leak if the node or conn startup
strings are present twice. In that case we will leak too. This should
not happen normally.
I made the attached patch and it fixed the leaks.
Thanks.
To be frank, I never understood the 'idbm_rec' logic completely.
I've just managed to solve this particular problem, and hadn't even
thought of checking for memory leaks.
So yes, we'd definitely need this one.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 1/8] ibft scanning fails on newer kernels
On 06/21/2011 11:39 PM, Mike Christie wrote: On 06/21/2011 04:23 AM, Hannes Reinecke wrote: Newer kernels provide the 'net' link as a directory, instead of the 'net:XX' link with previous kernels. The sysfs scanning code has enablement to work with this, but the directory lookup doesn't work properly. What is the bug exactly? What kernel does this break on? It seems to work ok for me. The patch seems like a enhancement and not a bug fix?? Before the patch the code would loop through everything in the dir. If that fails then it would drop down and look for just net. With your patch it now detects if we are doing net:XX or net when we first fine either one. Patch looks ok to me. Just want to make sure what is broken or not. Hmm. Now that you mention it. Indeed it's not required anymore. As the patch is rather old it's actually a merge artefact. So we wouldn't be needing it. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
[PATCH] iscsid sends SIGTERM to PID 0
Occasionally iscisd will send a SIGTERM to pid 0, causing
all sorts of weird things. Problem is that pid == 0 is
a valid return value for log_init(), so that all routines
only check for pid 0. However, as the signal handler
is inherited from the parent, even the logging thread
has a signal handler installed, for which the internal
pid is always '0'. So when a SIGTERM is send to the
logging thread, it'll forward the signal to PID 0.
References: bnc#589064
Signed-off-by: Hannes Reinecke h...@suse.de
diff --git a/usr/iscsid.c b/usr/iscsid.c
index 50c9b58..2e234fc 100644
--- a/usr/iscsid.c
+++ b/usr/iscsid.c
@@ -345,14 +345,6 @@ int main(int argc, char *argv[])
struct sigaction sa_new;
pid_t pid;
- /* do not allow ctrl-c for now... */
- sa_new.sa_handler = catch_signal;
- sigemptyset(sa_new.sa_mask);
- sa_new.sa_flags = 0;
- sigaction(SIGINT, sa_new, sa_old );
- sigaction(SIGPIPE, sa_new, sa_old );
- sigaction(SIGTERM, sa_new, sa_old );
-
while ((ch = getopt_long(argc, argv, c:i:fd:nu:g:p:vh, long_options,
longindex)) = 0) {
switch (ch) {
@@ -398,6 +390,14 @@ int main(int argc, char *argv[])
if (log_pid 0)
exit(1);
+ /* do not allow ctrl-c for now... */
+ sa_new.sa_handler = catch_signal;
+ sigemptyset(sa_new.sa_mask);
+ sa_new.sa_flags = 0;
+ sigaction(SIGINT, sa_new, sa_old );
+ sigaction(SIGPIPE, sa_new, sa_old );
+ sigaction(SIGTERM, sa_new, sa_old );
+
sysfs_init();
if (idbm_init(iscsid_get_config_file)) {
log_close(log_pid);
diff --git a/usr/log.c b/usr/log.c
index 62500cb..28e 100644
--- a/usr/log.c
+++ b/usr/log.c
@@ -458,6 +458,8 @@ void log_close(pid_t pid)
return;
}
- kill(pid, SIGTERM);
- waitpid(pid, status, 0);
+ if (pid 0) {
+ kill(pid, SIGTERM);
+ waitpid(pid, status, 0);
+ }
}
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
[PATCH 0/8] SUSE SLES resync
Hi Mike, it's the time of the year when the lilies blossom and I finally managed to get around sending my outstanding patches. Mose of them are some compability issues, with the occasional bug (cf the second patch) thrown in. Oh, and please ignore the previous two patches; I've generated them from my local tree and they won't apply properly. Hannes Reinecke (8): ibft scanning fails on newer kernels iscsid sends SIGTERM to PID 0 iscsid: Implement --no-pid-file Keep startup mode in sync when specified in config file Allow LOCK_DIR to be set via CFLAGS Allow 'onboot' as loginall parameter Update SUSE init script boot.suse: Update with latest fixes doc/iscsid.8|3 + etc/initd/boot.suse | 35 +-- etc/initd/initd.suse| 452 --- usr/idbm.c | 25 ++- usr/initiator.h |6 +- usr/iscsiadm.c | 19 +- usr/iscsid.c| 56 +++-- usr/log.c |6 +- utils/fwparam_ibft/fwparam_ibft_sysfs.c | 15 +- 9 files changed, 449 insertions(+), 168 deletions(-) -- 1.7.3.4 -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
[PATCH 1/8] ibft scanning fails on newer kernels
Newer kernels provide the 'net' link as a directory, instead of the
'net:XX' link with previous kernels. The sysfs scanning code has
enablement to work with this, but the directory lookup doesn't
work properly.
References: bnc#561596
Signed-off-by: Hannes Reinecke h...@suse.de
---
utils/fwparam_ibft/fwparam_ibft_sysfs.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/utils/fwparam_ibft/fwparam_ibft_sysfs.c
b/utils/fwparam_ibft/fwparam_ibft_sysfs.c
index 9185c85..486deec 100644
--- a/utils/fwparam_ibft/fwparam_ibft_sysfs.c
+++ b/utils/fwparam_ibft/fwparam_ibft_sysfs.c
@@ -84,7 +84,7 @@ static int find_sysfs_dirs(const char *fpath, const struct
stat *sb,
static int get_iface_from_device(char *id, struct boot_context *context)
{
char dev_dir[FILENAMESZ];
- int rc = ENODEV;
+ int rc = EOPNOTSUPP;
DIR *dirfd;
struct dirent *dent;
@@ -99,8 +99,7 @@ static int get_iface_from_device(char *id, struct
boot_context *context)
return errno;
while ((dent = readdir(dirfd))) {
- if (!strcmp(dent-d_name, .) || !strcmp(dent-d_name, ..) ||
- strncmp(dent-d_name, net:, 4))
+ if (!strcmp(dent-d_name, .) || !strcmp(dent-d_name, ..))
continue;
if (!strncmp(dent-d_name, net:, 4)) {
@@ -116,17 +115,19 @@ static int get_iface_from_device(char *id, struct
boot_context *context)
rc = EINVAL;
rc = 0;
break;
- } else {
- printf(Could not read ethernet to net link.\n);
- rc = EOPNOTSUPP;
+ }
+ if (!strcmp(dent-d_name, net)) {
+ rc = ENODEV;
break;
}
}
closedir(dirfd);
- if (rc != ENODEV)
+ if (rc != ENODEV) {
+ printf(Could not read ethernet to net link\n.);
return rc;
+ }
/* If not found try again with newer kernel networkdev sysfs layout */
strlcat(dev_dir, /net, FILENAMESZ);
--
1.7.3.4
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
[PATCH 2/8] iscsid sends SIGTERM to PID 0
Occasionally iscisd will send a SIGTERM to pid 0, causing
all sorts of weird things. Problem is that pid == 0 is
a valid return value for log_init(), so that all routines
only check for pid 0. However, as the signal handler
is inherited from the parent, even the logging thread
has a signal handler installed, for which the internal
pid is always '0'. So when a SIGTERM is send to the
logging thread, it'll forward the signal to PID 0.
References: bnc#589064
Signed-off-by: Hannes Reinecke h...@suse.de
---
usr/iscsid.c | 16
usr/log.c|6 --
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/usr/iscsid.c b/usr/iscsid.c
index 67a6944..3fa3295 100644
--- a/usr/iscsid.c
+++ b/usr/iscsid.c
@@ -339,14 +339,6 @@ int main(int argc, char *argv[])
int control_fd;
pid_t pid;
- /* do not allow ctrl-c for now... */
- sa_new.sa_handler = catch_signal;
- sigemptyset(sa_new.sa_mask);
- sa_new.sa_flags = 0;
- sigaction(SIGINT, sa_new, sa_old );
- sigaction(SIGPIPE, sa_new, sa_old );
- sigaction(SIGTERM, sa_new, sa_old );
-
while ((ch = getopt_long(argc, argv, c:i:fd:u:g:p:vh, long_options,
longindex)) = 0) {
switch (ch) {
@@ -390,6 +382,14 @@ int main(int argc, char *argv[])
if (log_pid 0)
exit(ISCSI_ERR);
+ /* do not allow ctrl-c for now... */
+ sa_new.sa_handler = catch_signal;
+ sigemptyset(sa_new.sa_mask);
+ sa_new.sa_flags = 0;
+ sigaction(SIGINT, sa_new, sa_old );
+ sigaction(SIGPIPE, sa_new, sa_old );
+ sigaction(SIGTERM, sa_new, sa_old );
+
sysfs_init();
if (idbm_init(iscsid_get_config_file)) {
log_close(log_pid);
diff --git a/usr/log.c b/usr/log.c
index 9d5f933..5747554 100644
--- a/usr/log.c
+++ b/usr/log.c
@@ -474,6 +474,8 @@ void log_close(pid_t pid)
return;
}
- kill(pid, SIGTERM);
- waitpid(pid, status, 0);
+ if (pid 0) {
+ kill(pid, SIGTERM);
+ waitpid(pid, status, 0);
+ }
}
--
1.7.3.4
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
[PATCH 3/8] iscsid: Implement --no-pid-file
For root on iSCSI scenarios the /var directory might not exist.
And we don't need the pid file anyway as the daemon is synchronized
via the IPC connection.
Signed-off-by: Hannes Reinecke h...@suse.de
---
doc/iscsid.8 |3 +++
usr/iscsid.c | 40
2 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/doc/iscsid.8 b/doc/iscsid.8
index 1dfa1e5..92b7f81 100644
--- a/doc/iscsid.8
+++ b/doc/iscsid.8
@@ -35,6 +35,9 @@ run under user ID \fIuid\fR (default is the current user ID)
.BI [-g|--gid=]\fIgid\fP
run under user group ID \fIgid\fR (default is the current user group ID).
.TP
+.BI [-n|--no-pid-file]\fP
+do not write a process ID file.
+.TP
.BI [-p|--pid=]\fIpid\-file\fP
write process ID to \fIpid\-file\fR rather than the default
\fI/var/run/iscsid.pid\fR
diff --git a/usr/iscsid.c b/usr/iscsid.c
index 3fa3295..1a37347 100644
--- a/usr/iscsid.c
+++ b/usr/iscsid.c
@@ -69,6 +69,7 @@ static struct option const long_options[] = {
{debug, required_argument, NULL, 'd'},
{uid, required_argument, NULL, 'u'},
{gid, required_argument, NULL, 'g'},
+ {no-pid-file, no_argument, NULL, 'n'},
{pid, required_argument, NULL, 'p'},
{help, no_argument, NULL, 'h'},
{version, no_argument, NULL, 'v'},
@@ -90,6 +91,7 @@ Open-iSCSI initiator daemon.\n\
-d, --debug debuglevel print debugging information\n\
-u, --uid=uid run as uid, default is current user\n\
-g, --gid=gid run as gid, default is current user group\n\
+ -n, --no-pid-file do not use a pid file\n\
-p, --pid=pidfile use pid file (default PID_FILE ).\n\
-h, --help display this help and exit\n\
-v, --version display version and exit\n\
@@ -339,7 +341,7 @@ int main(int argc, char *argv[])
int control_fd;
pid_t pid;
- while ((ch = getopt_long(argc, argv, c:i:fd:u:g:p:vh, long_options,
+ while ((ch = getopt_long(argc, argv, c:i:fd:nu:g:p:vh, long_options,
longindex)) = 0) {
switch (ch) {
case 'c':
@@ -360,6 +362,9 @@ int main(int argc, char *argv[])
case 'g':
gid = strtoul(optarg, NULL, 10);
break;
+ case 'n':
+ pid_file = NULL;
+ break;
case 'p':
pid_file = optarg;
break;
@@ -415,13 +420,15 @@ int main(int argc, char *argv[])
if (daemonize) {
char buf[64];
- int fd;
-
- fd = open(pid_file, O_WRONLY|O_CREAT, 0644);
- if (fd 0) {
- log_error(Unable to create pid file);
- log_close(log_pid);
- exit(ISCSI_ERR);
+ int fd = -1;
+
+ if (pid_file) {
+ fd = open(pid_file, O_WRONLY|O_CREAT, 0644);
+ if (fd 0) {
+ log_error(Unable to create pid file);
+ log_close(log_pid);
+ exit(ISCSI_ERR);
+ }
}
pid = fork();
if (pid 0) {
@@ -439,15 +446,16 @@ int main(int argc, char *argv[])
}
chdir(/);
- if (lockf(fd, F_TLOCK, 0) 0) {
- log_error(Unable to lock pid file);
- log_close(log_pid);
- exit(ISCSI_ERR);
+ if (fd 0) {
+ if (lockf(fd, F_TLOCK, 0) 0) {
+ log_error(Unable to lock pid file);
+ log_close(log_pid);
+ exit(ISCSI_ERR);
+ }
+ ftruncate(fd, 0);
+ sprintf(buf, %d\n, getpid());
+ write(fd, buf, strlen(buf));
}
- ftruncate(fd, 0);
- sprintf(buf, %d\n, getpid());
- write(fd, buf, strlen(buf));
-
daemon_init();
} else {
if ((control_fd = ipc-ctldev_open()) 0) {
--
1.7.3.4
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
[PATCH 5/8] Allow LOCK_DIR to be set via CFLAGS
For root on iSCSI we have to move idbm's LOCK_DIR to eg /etc/iscsi,
as the /var directory might not be available. So make it configurable
during compile-time.
Signed-off-by: Hannes Reinecke h...@suse.de
---
usr/initiator.h |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/usr/initiator.h b/usr/initiator.h
index 93e9b3b..8497c70 100644
--- a/usr/initiator.h
+++ b/usr/initiator.h
@@ -39,9 +39,11 @@
#define INITIATOR_NAME_FILEISCSI_CONFIG_ROOTinitiatorname.iscsi
#define PID_FILE /var/run/iscsid.pid
+#ifndef LOCK_DIR
#define LOCK_DIR /var/lock/iscsi
-#define LOCK_FILE /var/lock/iscsi/lock
-#define LOCK_WRITE_FILE/var/lock/iscsi/lock.write
+#endif
+#define LOCK_FILE LOCK_DIR/lock
+#define LOCK_WRITE_FILELOCK_DIR/lock.write
typedef enum iscsi_conn_state_e {
STATE_FREE,
--
1.7.3.4
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
[PATCH 6/8] Allow 'onboot' as loginall parameter
We are using to 'onboot' parameter to setup iscsi connections
in the initrd. Thus we should be able to use 'onboot' as a valid
parameter for loginall, too.
References: 449108
Signed-off-by: Hannes Reinecke h...@suse.de
---
usr/iscsiadm.c | 19 +--
1 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/usr/iscsiadm.c b/usr/iscsiadm.c
index 5972d01..e3a6b81 100644
--- a/usr/iscsiadm.c
+++ b/usr/iscsiadm.c
@@ -265,15 +265,10 @@ static int print_ifaces(struct iface_rec *iface, int
info_level)
static int
match_startup_mode(node_rec_t *rec, char *mode)
{
- /*
-* we always skip onboot because this should be handled by
-* something else
-*/
- if (rec-startup == ISCSI_STARTUP_ONBOOT)
- return -1;
-
if ((!strcmp(mode, automatic)
rec-startup == ISCSI_STARTUP_AUTOMATIC) ||
+ (!strcmp(mode, onboot)
+ rec-startup == ISCSI_STARTUP_ONBOOT) ||
(!strcmp(mode, manual)
rec-startup == ISCSI_STARTUP_MANUAL) ||
!strcmp(mode, all))
@@ -282,6 +277,8 @@ match_startup_mode(node_rec_t *rec, char *mode)
/* support conn or session startup params */
if ((!strcmp(mode, automatic)
rec-conn[0].startup == ISCSI_STARTUP_AUTOMATIC) ||
+ (!strcmp(mode, onboot)
+ rec-conn[0].startup == ISCSI_STARTUP_ONBOOT) ||
(!strcmp(mode, manual)
rec-conn[0].startup == ISCSI_STARTUP_MANUAL) ||
!strcmp(mode, all))
@@ -385,12 +382,6 @@ static int
__login_by_startup(void *data, struct list_head *list, struct node_rec *rec)
{
char *mode = data;
- /*
-* we always skip onboot because this should be handled by
-* something else
-*/
- if (rec-startup == ISCSI_STARTUP_ONBOOT)
- return -1;
if (match_startup_mode(rec, mode))
return -1;
@@ -405,7 +396,7 @@ login_by_startup(char *mode)
struct list_head rec_list;
if (!mode || !(!strcmp(mode, automatic) || !strcmp(mode, all) ||
- !strcmp(mode,manual))) {
+ !strcmp(mode,manual) || !strcmp(mode, onboot))) {
log_error(Invalid loginall option %s., mode);
usage(ISCSI_ERR_INVAL);
return ISCSI_ERR_INVAL;
--
1.7.3.4
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
[PATCH 7/8] Update SUSE init script
Rework the iSCSI shutdown logic to tear down the block device
stack correctly.
Signed-off-by: Hannes Reinecke h...@suse.de
---
etc/initd/initd.suse | 452 +++---
1 files changed, 354 insertions(+), 98 deletions(-)
diff --git a/etc/initd/initd.suse b/etc/initd/initd.suse
index a587aff..1829419 100644
--- a/etc/initd/initd.suse
+++ b/etc/initd/initd.suse
@@ -5,20 +5,22 @@
### BEGIN INIT INFO
# Provides: iscsi
# Required-Start:$network
-# Should-Start: iscsitarget
-# Required-Stop:
-# Should-Stop:
+# Should-Start: iscsitarget multipathd
+# Required-Stop: $network
+# Should-Stop: multipathd
# Default-Start: 3 5
# Default-Stop:
-# Short-Description: Starts and stops the iSCSI client initiator
+# Short-Description: iSCSI initiator daemon
+# Description: The iSCSI initator is used to create and
+#manage iSCSI connections to a iSCSI Target.
#
### END INIT INFO
-PID_FILE=/var/run/iscsi.pid
CONFIG_FILE=/etc/iscsi/iscsid.conf
DAEMON=/sbin/iscsid
ISCSIADM=/sbin/iscsiadm
-ARGS=-c $CONFIG_FILE -p $PID_FILE
+BRCM_ISCSIUIO=/sbin/brcm_iscsiuio
+ARGS=-c $CONFIG_FILE -n
# Source LSB init functions
. /etc/rc.status
@@ -26,6 +28,8 @@ ARGS=-c $CONFIG_FILE -p $PID_FILE
# Reset status of this service
rc_reset
+DM_MAJOR=$(sed -n 's/\(.*\) device-mapper/\1/p' /proc/devices)
+
iscsi_login_all_nodes()
{
echo -n Setting up iSCSI targets:
@@ -36,58 +40,349 @@ iscsi_login_all_nodes()
rc_status -v
}
-iscsi_logout_all_nodes()
+#
+# Try to load all required modules prior to startup
+#
+iscsi_load_transport_modules()
{
- echo -n Closing all iSCSI connections:
- # Logout from all sessions marked automatic
- if ! $ISCSIADM -m node --logoutall=automatic 2 /dev/null; then
- if [ $? == 21 ] ; then
- RETVAL=6
- else
- RETVAL=1
+loaded=$(sed -n /^iscsi_tcp/p /proc/modules)
+if [ -z $loaded ] ; then
+ modprobe iscsi_tcp
+ if [ $? = 0 ] ; then
+ echo -n tcp
+ fi
+fi
+
+for iface in /etc/iscsi/ifaces/*; do
+ [ -f $iface ] || continue
+ [ $iface = iface.example ] continue
+ # Check if the iface has been configured
+ result=$(sed
'/#.*/D;/iface.iscsi_ifacename/D;/iface.hwaddress/D;/iface.transport_name/D'
$iface)
+ if [ $result ] ; then
+ mod=$(sed -n 's/iface.transport_name *= *\(.*\)/\1/p' $iface)
+ loaded=$(sed -n /^$mod/p /proc/modules)
+ if [ -z $loaded ] ; then
+ modprobe $mod
+ if [ $? = 0 ] ; then
+ echo -n $mod
fi
- rc_failed $RETVAL
+ fi
fi
- rc_status -v
+done
+}
- # Not sure whether this is still needed
- sleep 1
- return ${RETVAL:-0}
+#
+# Set a temporary startmode for ifdown
+#
+iscsi_modify_if_startmode()
+{
+local ifname=$1
+local tmp_ifcfg=/dev/.sysconfig/network/if-$ifname
+
+if [ -e $tmp_ifcfg ] ; then
+ . $tmp_ifcfg
+ if [ $startmode ] ; then
+ return
+ fi
+fi
+: disabling shutdown on $ifname
+echo startmode=nfsroot $tmp_ifcfg
}
-iscsi_umount_all_luns()
+iscsi_get_ifacename_from_session()
{
-local d m dev p s
+local session=$1
+local ifacename
-cat /proc/mounts | sed -ne '/^\/dev\/.*/p' | while read d m t o x; do
- if [ $m = / ] ; then
- continue;
+ifacename=$(iscsiadm -m session -r ${session##.*/session} 2 /dev/null | \
+ sed -n 's/iface.iscsi_ifacename = \(.*\)/\1/p')
+if [ -z $ifacename ] ; then
+ # Check for iBFT
+ ifacename=$(iscsiadm -m fw 2 /dev/null)
+ if [ -n $ifacename ] ; then
+ ifacename=fw
fi
+fi
+echo $ifacename
+}
+
+iscsi_get_hwaddress_from_iface()
+{
+local iface=$1
+local hwaddress
+
+hwaddress=$(iscsiadm -m iface -I $iface 2 /dev/null | sed -n
's/iface.hwaddress = \(.*\)/\1/p')
+[ $hwaddress = empty ] hwaddress=
+
+echo $hwaddress
+}
+
+iscsi_get_ifname_from_iface()
+{
+local iface=$1
+local ifname
+
+ifname=$(iscsiadm -m iface -I $iface 2 /dev/null | sed -n
's/iface.net_ifacename = \(.*\)/\1/p')
+[ $ifname = empty ] ifname=
+
+echo $ifname
+}
+
+iscsi_get_ipaddr_from_iface()
+{
+local iface=$1
+local ipaddr
+
+ipaddr=$(iscsiadm -m iface -I $iface 2 /dev/null | sed -n
's/iface.ipaddress = \(.*\)/\1/p')
+[ $ipaddr = empty ] ipaddr=
+
+echo $ipaddr
+}
+
+iscsi_get_ifname_from_firmware()
+{
+local hwaddress
+
+hwaddress=$(iscsiadm -m fw 2 /dev/null | sed -n 's/iface.net_ifacename =
\(.*\)/\1/p')
+
+echo $hwaddress
+}
+
+#
+# cxgb3i is using the HWAddress to select
+# the correct interface
+#
+iscsi_get_ifname_from_hwaddress()
+{
+local hwaddress=$1
+
+for if in /sys/class/net/*; do
[PATCH 8/8] boot.suse: Update with latest fixes
Include latest fixes from SUSE.
Signed-off-by: Hannes Reinecke h...@suse.de
---
etc/initd/boot.suse | 35 +++
1 files changed, 15 insertions(+), 20 deletions(-)
diff --git a/etc/initd/boot.suse b/etc/initd/boot.suse
index df64e21..ac6abcc 100644
--- a/etc/initd/boot.suse
+++ b/etc/initd/boot.suse
@@ -4,36 +4,37 @@
#
### BEGIN INIT INFO
# Provides: iscsiboot
-# Required-Start:boot.proc
-# Should-Start:
-# Required-Stop:
+# Required-Start:
+# Should-Start: boot.multipath
+# Required-Stop:
# Should-Stop:
# Default-Start: B
# Default-Stop:
-# Short-Description: Starts the iSCSI initiator daemon
-#
+# Short-Description: iSCSI initiator daemon root-fs support
+# Description: Starts the iSCSI initiator daemon if the
+#root-filesystem is on an iSCSI device
+#
### END INIT INFO
ISCSIADM=/sbin/iscsiadm
-PID_FILE=/var/run/iscsi.pid
CONFIG_FILE=/etc/iscsid.conf
DAEMON=/sbin/iscsid
-ARGS=-c $CONFIG_FILE -p $PID_FILE
+ARGS=-c $CONFIG_FILE
# Source LSB init functions
. /etc/rc.status
#
-# This service is run right after booting. So all activated targets
-# must be enabled during mkinitrd run and thus should not be removed
-# when the open-iscsi service is stopped.
+# This service is run right after booting. So all targets activated
+# during mkinitrd run should not be removed when the open-iscsi
+# service is stopped.
#
iscsi_mark_root_nodes()
{
$ISCSIADM -m session 2 /dev/null | while read t num i target ; do
ip=${i%%:*}
- STARTUP=`$ISCSIADM -m node -p $ip -T $target | grep
node.conn\[0\].startup | cut -d' ' -f3`
- if [ $STARTUP != onboot ] ; then
+ STARTUP=`$ISCSIADM -m node -p $ip -T $target 2 /dev/null | grep
node.conn\[0\].startup | cut -d' ' -f3`
+ if [ $STARTUP -a $STARTUP != onboot ] ; then
$ISCSIADM -m node -p $ip -T $target -o update -n
node.conn[0].startup -v onboot
fi
done
@@ -50,13 +51,12 @@ fi
case $1 in
start)
- [ ! -d /var/lib/open-iscsi ] mkdir -p /var/lib/open-iscsi
echo -n Starting iSCSI initiator for the root device:
startproc $DAEMON $ARGS
rc_status -v
iscsi_mark_root_nodes
;;
-stop)
+stop|restart|reload)
rc_failed 0
;;
status)
@@ -68,13 +68,8 @@ case $1 in
rc_status -v
fi
;;
-restart)
- $0 stop
- sleep 1
- $0 start
- ;;
*)
- echo Usage: $0 {start|stop|status|restart}
+ echo Usage: $0 {start|stop|status|restart|reload}
exit 1
;;
esac
--
1.7.3.4
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: Kernel NULL pointer dereference [when using iser]
On 03/28/2011 11:13 AM, Or Gerlitz wrote: On 3/27/2011 7:46 PM, Stepan Fedorov wrote: We use SLES. May be we can backport this fix to SLES 2.6.32 kernel? I can look on that, any idea/pointer for public download of the src rpm for their kernel? Also, I wasn't sure who's the SLES maintainer for iscsi nowadays, Hannes, is that still you? If and when customer escalations leave me some leeway to move, yes, that'll be me. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: iscsiadm: discovery record not found
On 02/19/2011 05:45 AM, Mike Christie wrote:
On 02/18/2011 08:59 PM, Dr. Ed Morbius wrote:
Trying to set up a number of initiators on CentOS 5.5 with a Dell
MD32xxi target.
I've successfully configured several other identical initiators with
these targets.
$ export DP=dataport IP
$ sudo iscsiadm -m discoverydb -t sendtargets -p $DP:3260
iscsiadm: Discovery record [$DP,3260] not found.
I've got records in /var/lib/iscsi/ifaces, but no other /var/lib/iscsi/
subdirectories.
Have you done discovery to that address,port or done a -o new to create
a db discovery record for it? If not then that is what you would expect.
You can do
sudo iscsiadm -m discoverydb -t sendtargets -p $DP:3260 -D
without the -D, then iscsiadm is just looking for the discovery record
for that discovery address,port.
To have iscsiadm try to do discovery pass it the -D argument or do the
old style
iscsiadm -m discovery -t st -p ip:port
(no db in the discovery mode name).
I have just stumbled upon this issue, too.
And found it pretty awkward to use; after all, to all intents and
purposes the hostname and the IP-address can be used interchangeably.
I (and our QA :-( ) don't see a reason why should draw a blank here.
So after long hours of debugging I came up with this patch, which
resolves the hostname into the IP address and uses this for lookup.
Mike, comments?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
From: Hannes Reinecke h...@suse.de
Date: Wed, 23 Feb 2011 10:06:50 +0100
Subject: [PATCH] iscsiadm: fixup discovery records display
Sendtargets discovery is using the passed in address to lookup
the existing records in the database. However, as this can either
be the hostname or the IP address it is getting confused and won't
find existing records when called with the other address.
So we should be resolving the hostname into the IP address
when looking up records in the database.
Signed-off-by: Hannes Reinecke h...@suse.de
diff --git a/usr/iscsiadm.c b/usr/iscsiadm.c
index 1478c7b..6fe4151 100644
--- a/usr/iscsiadm.c
+++ b/usr/iscsiadm.c
@@ -2371,7 +2371,8 @@ main(int argc, char **argv)
memset(drec, 0, sizeof(discovery_rec_t));
idbm_sendtargets_defaults(db, drec.u.sendtargets);
- strncpy(drec.address, ip, sizeof(drec.address));
+ if (address_to_ip(ip, drec.address) 0)
+ strncpy(drec.address, ip, sizeof(drec.address));
drec.port = port;
if (do_sendtargets(db, drec, ifaces, info_level,
diff --git a/usr/util.c b/usr/util.c
index 8e74dfd..9f7aeed 100644
--- a/usr/util.c
+++ b/usr/util.c
@@ -7,6 +7,8 @@
#include sys/un.h
#include sys/time.h
#include sys/resource.h
+#include arpa/inet.h
+#include netdb.h
#include log.h
#include actor.h
@@ -88,6 +90,34 @@ str_to_ipport(char *str, int *port, int *tpgt)
return ip;
}
+int address_to_ip(char *address, char *ipaddr)
+{
+ int ret;
+ struct addrinfo *ai_list, *aip;
+ struct sockaddr_in *sinp;
+ const char *addrp = NULL;
+
+ if ((ret = getaddrinfo (address, NULL,
+ NULL, ai_list)) != 0) {
+ log_warning(getaddrinfo for %s failed: %s,
+ address, gai_strerror(ret));
+ return -EINVAL;
+ }
+ for (aip = ai_list; aip != NULL; aip = aip-ai_next) {
+ if (aip-ai_family == AF_INET) {
+ sinp = (struct sockaddr_in *)aip-ai_addr;
+ addrp = inet_ntop(aip-ai_family,
+ sinp-sin_addr,
+ ipaddr, INET_ADDRSTRLEN);
+ if (addrp)
+ return 0;
+ }
+ }
+ /* Fallback if we couldn't resolve the address */
+ log_debug(5, Couldn't resolve address %s, address);
+ return -EADDRNOTAVAIL;
+}
+
#define ISCSI_MAX_FILES 16384
int increase_max_files(void)
diff --git a/usr/util.h b/usr/util.h
index 9176ca9..21d1279 100644
--- a/usr/util.h
+++ b/usr/util.h
@@ -20,6 +20,7 @@ extern int iscsid_response(int fd, int cmd, struct
iscsiadm_rsp *rsp);
extern char *str_to_ipport(char *str, int *port, int *tgpt);
extern void idbm_node_setup_defaults(struct node_rec *rec);
+extern int address_to_ip(char *address, char *ipaddr
iSCSI connection errors with SLES10 SP3 update
Hi all, I just noticed that I've botched up header digests with the latest update for SLES10 SP3. So if you got trouble connecting and get loads of 'iscsi: detected conn error (1011)' please switch off header digests. I'm working on fixing this and will let you know once the issue is fixed. Sorry about this. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: iSCSI connection errors with SLES10 SP3 update
On 12/20/2010 09:56 AM, Hannes Reinecke wrote: Hi all, I just noticed that I've botched up header digests with the latest update for SLES10 SP3. So if you got trouble connecting and get loads of 'iscsi: detected conn error (1011)' please switch off header digests. I'm working on fixing this and will let you know once the issue is fixed. Sorry about this. After a short test I found this is due to the missing commit 96b1f96dcab87756c0a1e7ba76bc5dc2add82b88 fix fixes header digests (again). Patch will be included in the next maintenance update. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: DCB support for iSCSI
On 12/17/2010 06:55 PM, Rustad, Mark D wrote: Hi all, I am looking into adding support for DCB into iSCSI. I think it is best to do this in a way that will not require a strong dependency on DCB for iSCSI. That is, installing open-iscsi should not then require open-lldp to also be installed. I see at least two ways to do this. The first is to have open-lldp supply a library that iscsid can link with at run time (through dlopen/dlsym). In that way, if the library is not there, iscsid can go on as usual. It also allows lldpad more freedom to change over time. The second way is to put a little more code directly in iscsid and have it interrogate lldpad for the proper priority to set. If the lldpad socket isn't there, iscsid can go on as usual. I am thinking that open-lldp can supply the source files that would be placed directly into open-iscsi and updated as needed. These source files might also be used by other network applications that want to participate fully in a DCB environment. I had been leaning toward the first way until I started thinking about iscsistart and initrds. Then it seemed that the run-time linkage would create more trouble than it would be worth. It started to seem like over-engineering. I would prefer the second method. DCB configuration itself is quite involved and requires to negotiate the transfer parameter before the connection is setup. And as DCB is in fact quite a different beast from iSCSI we should keep it as a separate daemon. Which would also be in-line with the current fcoeadm setup. In either case, I was thinking about adding code right before the connect() call in iscsi_io_tcp_connect to set the socket options based on information from lldpad. Is anything more than that needed (besides doing something similar in iscsistart)? VLAN creation. From what I've seen iSCSI support in DCB would work similar to FCoE, ie the iSCSI traffic will be sent via a separate VLAN. Which we would need to create, eventually. So basically we would need something similar to 'fipvlan' or integrate this functionality into open-iscsi. The socket protocol to lldpad is already versioned, so that should prevent any terribly rude surprises in the future should mismatched components be used together. Does this sound reasonable to you? Would you rather see it done in a different way? Would you prefer for iscsid to simply send a file descriptor to the lldpad socket and have lldpad set the socket options itself? Ugh. No. As mentioned, I fear we would need to setup a VLAN interface here, in which case we would be running off a totally different socket anyway. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: Antw: Re: Q: RAID1 with open-iscsi
Mike Christie wrote: Hey again Hannes, On 10/08/2010 01:34 AM, Ulrich Windl wrote: Mike Christiemicha...@cs.wisc.edu schrieb am 08.10.2010 um 05:07 in Nachricht4cae8b0a.9050...@cs.wisc.edu: On 10/07/2010 08:43 AM, Ulrich Windl wrote: Hi, a question: From what I've read, md won't work with open-iscsi (in SLES10). What options do exist to have a RAID1 setup using two different storage systems? I only have experience with md and local disks. I have never heard that. Why doesn't it work? Is it a problem with md's design or RAID in general. What about device mapper (dm] RAID? SLES10 SP3 Release Notes (/usr/share/doc/release-notes/SUSE_Linux_Enterprise_Server_10/release-notes.txt) say in Chapter 5. Installation-Related Notes (lines 316-338): ● MD Devices on top of iSCSI not possible iSCSI devices cannot be used for Linux Software RAID. Using MD devices on top of iSCSI triggers a cyclic dependency that leads to a crash. I have never seen that before. What is the problem? Is it something that I need to fix in iscsi? Is it due to threading priorities? Ah. Same here. I don't think this is something I ever tested, so I wonder where this comes from ... Might be a stale info back from older version. I'll investigate. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH RFC/RFT] add iscsi dev loss timeout and device removal
Mike Christie wrote: Hey, At storage summit this year, it was decided iscsi needs to catch up with the other iscsi drivers, and add something like FC's dev_loss_tmo. When this timeout expires, it will cause the iscsi layer to remove the scsi devices and fail any IO that was queued. Upper layers like dm-multipath (actually multipathd and dm-multipath work together) then handle hotplug removal events from the device deletion event, by removing paths from the dm-multipath device. When the session gets logged back in, we kick off a scan and re-find devices. multipathd and dm-multipath then handle this by adding the paths back to the multipath device. If you are not using dm-multipath and are mounting the FS on the iscsi device then you basically see the same thing as before. IO errors, followed by the FS getting mounted read only. This patch will also fix a problem where if a device is offlined due to the transport going kaput scsi_internal_device_unblock() would not set the device back to running. With this patch the device gets destroyed and a new one gets added, so we completely bypass that problem like how FC and SAS does (note: it does not address the problem with iscsi_block_eh races - waiting on the fc discussion). This patch was made over Linus's tree but can be applied to scsi-misc or scsi-rc-fixes. I have only done some light testing. I wanted to post this though, so other driver developers could test it out. Hmm. I do remember you telling me that using recovery_tmo should serve exactly the same purpose. Yet you implement it at totally different angle, leaving recovery_tmo untouched. I would have expected some integration there And, in fact, I think it might be more worthwhile to have a 1:1 mapping between recovery_tmo and dev_loss_tmo and implement a new handling for fast_io_fail, which would be quite attractive to iscsi, too. Apart from that: good point. I was on the verge of updating multipath-tools to checking/modifying recovery_tmo for iSCSI, but maybe I'll wait for a few days. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: detected conn error (1011)
On Thu, Sep 02, 2010 at 03:15:31PM -0700, Shantanu Mehendale wrote: Hi Hannes/Mike, I am also dealing with another issue on ISCSI transport where I am seeing DID_TRASNPORT_FAILFAST hostbyte errors reaching the application which is sending I/O on a device-mapper node. Reading the code a little I thought that after the iscsi replacement_timeout timer fires, the io stuck in the io queues will be sent up to the device-mapper, which would send the io to the new path. Is there a possibility that dm-multipath is not able to handle all the errors so some of them end up going to the application. Basically this is a cable pull kind of experiment where we would expect the path failover to work and io to continue properly. Yes, in general it should. And yes, multipath should handle these cases. But I did quite some patches to iSCSI in SLES11, so you should be making sure you're using the latest maintenance release. Since we already saw one problem with DID_TRANSPORT_DISRUPTED, I was wondering if DID_TRANSPORT_FAILFAST also has some similar issues with limited retries and such. No, that's actually okay. The I/O error will be reported in either case, it's just that it'll never reaches the upper layers. In your case it looks as if the 'tapdisk' thing runs on the raw disks, not the multipathed device. So of course it'll register the error. Maybe it's an idea to have the 'tapdisk' run on the multipath device-mapper device ... Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: detected conn error (1011)
Goncalo Gomes wrote:
Hi Hannes,
Thanks. The Citrix XenServer 5.6 distribution kernel is based on the 2.6.27
tree of SLES 11.
We add a few extra patches specific to Xen, dom0 integration and some
backports from upstream.
To the best of my knowledge these additions don't touch the iscsi layer, so
from the iscsi
drivers point of view, I believe they are as pristine as the ones in the SuSE
kernel and that's
why we need the patch as the binaries probably will mismatch gcc version
and/or the versioning
that we use e.g 2.6.27.42-0.1.1.xs5.6.0.44.58xen. I do definitely
appreciate your
'forward thinking' with regards to the issue, though!
I just checked, and the resulting patch is indeed like you proposed:
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 32b30f1..441ca8b 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -1336,9 +1336,6 @@ int iscsi_queuecommand(struct scsi_cmnd *sc, void (*done)(
struct scsi_cmnd *))
*/
switch (session-state) {
case ISCSI_STATE_FAILED:
- reason = FAILURE_SESSION_FAILED;
- sc-result = DID_TRANSPORT_DISRUPTED 16;
- break;
case ISCSI_STATE_IN_RECOVERY:
reason = FAILURE_SESSION_IN_RECOVERY;
sc-result = DID_IMM_RETRY 16;
HTH,
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: detected conn error (1011)
Goncalo Gomes wrote: Hi, On Fri, 2010-08-06 at 15:57 +0100, Hannes Reinecke wrote: Mike Christie wrote: ccing Hannes from suse, because this looks like a SLES only bug. Hey Hannes, The user is using Linux 2.6.27 x86 based on SLES + Xen 3.4 (as dom0) running a couple of RHEL 5.5 VMs. The underlying storage for these VMs is iSCSI based via open-iscsi 2.0.870-26.6.1 and a DELL equallogic array. On 08/05/2010 02:21 PM, Goncalo Gomes wrote: I've copied both the messages file from the host goncalog140 and the patched libiscsi.c. FWIW, I've also included the iscsid.conf. Find these files in the link below: http://promisc.org/iscsi/ It looks like this chunk from libiscsi.c:iscsi_queuecommand: case ISCSI_STATE_FAILED: reason = FAILURE_SESSION_FAILED; sc-result = DID_TRANSPORT_DISRUPTED 16; break; is causing IO errors. You want to use something like DID_IMM_RETRY because it can be a long time between the time the kernel marks the state as ISCSI_STATE_FAILED until we start recovery and properly get all the device queues blocked, so we can exhaust all the retries if we use DID_TRANSPORT_DISRUPTED. Yeah, I noticed. But the problem is that multipathing will stall during this time, ie no failover will occur and I/O will stall. Using DID_TRANSPORT_DISRUPTED will circumvent this and we can failover immediately. Sadly I got additional bugreports about this so I think I'll have to revert it. I applied and tested the changes Mike Christie suggests. After the LUN is rebalanced within the array I no longer see the IO errors and it appears the setup is now resilient to the equallogic LUN failover process. I'm attaching the log from the dmesg merely for sanity check purposes, if anyone cares to take a look? I have put some test kernels at http://beta.suse.com/private/hare/sles11/iscsi Do the test kernels in the url above contain the change of DID_TRANSPORT_DISRUPTED to DID_DIMM_RETRY or is there more to it than simply changing the result code? If the latter, would you be able to upload the source rpms or a unified patch containing the changes you are are staging? I'm looking for a more pallatable way to test them, given I have no SLES box lying around, but will install one if needs be. Got me confused. How would you test the patch if not on a SLES box? Presumably you would have to install the new kernel on the instance you are planning to run the test on. Which for any sane setup would have to be a SLES box. In which case you can just use the provided kernel directly and save you the compilation step. Am I missing something? Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH] support NIC configuration in iBFT
Mike Christie wrote: On 01/07/2010 08:16 AM, Alex Zeffertt wrote: Mike Christie wrote: Thanks for doing this. Sorry for the late reply. Just one comment on the patch. Could you move the code in the 'n' case + case 'n': + /* + * Bring up NICs required by targets in iBFT + * using IP addresses and routing info from iBFT. + */ .. to some helper function, so it is not so crowed and a little easier to read? No problem. Please find a new patch attached. Merged in commit 39f4761231e2aa20b468cd5258785d6f56472772. It should show up in the git tree in a little bit and in the next major release. Thanks! Finally found some time to comment on this one. In principle this is a good idea; it certainly saves quite some trouble for eg initrd as we don't have to worry about interface naming etc. However: Having iscsiadm setting up the network interfaces we do have the problem that we're doing it alongside the 'normal' system network configuration. IE the system hasn't any idea that we've already configured the interface nor how it should handle it. This is especially a problem during shutdown, where the networking scripts are prone to shutdown any unknown interface. And having the networking scripts calling out to iscsiadm is not earning us much favours I would assume. A possible route here would be to modify the networking scripts to check the ibft variables; however, this requires quite some bit of sysfs tree walking. And given the somewhat fluctuating nature of sysfs it will earn us even less favours. It would be cool if we had an 'ibft' link in the network interface, though ... Hmm. Maybe I can trick Kay Sievers into doing one ... But apart from that is a pretty cool thing. It especially fixes the problem we have right now that changes in the iBFT BIOS are not picked up once the machines are installed. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: SLES10 SP3 x86_64 - connection2:0: detected conn error (1011)
avora wrote: With SLES10 SP3 x86_64, as soon as I start the second iscsi session2, I am very frequently getting the connection errors/ I do not see this with SLES10 SP2 x86_64 on the same setup. Dec 7 18:42:05 cdc-r710s1 kernel: connection2:0: detected conn error (1011) Dec 7 18:42:06 cdc-r710s1 iscsid: connection2:0 is operational after recovery (1 attempts) Dec 7 18:42:06 cdc-r710s1 iscsid: Kernel reported iSCSI connection 2:0 error (1011) state (3) Dec 7 18:42:08 cdc-r710s1 kernel: connection2:0: detected conn error (1011) I have tried changing noop_out_interval and noop_out_timeout to 120/120 and 0/0 but did not help. The iscsiadm settings are same on both SP2 and SP3. Is there anything else that can be tried ? # iscsiadm --mode node --targetname target ... # rpm -qa | grep iscsi iscsitarget-0.4.17-3.4.25 open-iscsi-2.0.868-0.6.11 yast2-iscsi-client-2.14.47-0.4.9 yast2-iscsi-server-2.13.26-0.3 Please try with the latest update kernel. I made quite some fixes which should help here. cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: open-iscsi on SUSE 11
Stuart Little wrote: Hi, Using open-iscsi-2.0.869-8.1 (x86_64) on a SUSE 11.0 based machine, connecting to an HP D2D. Is that OpenSUSE 11.0 or SLES11? I only do _very_ limited testing on OpenSUSE, so SLES is the preferred platform if you really want to test iSCSI. I would recommend recompiling the latest open-iscsi code by hand for OpenSUSE. Sorry for this, but I fear I'm slightly overloaded... Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH] Allow empty username for CHAP
Mike Christie wrote: On 09/29/2009 08:46 AM, Hannes Reinecke wrote: Some iSCSI implementations (eg HP) is using an empty username for CHAP negotiations. So we should be allowing the same. Do we need this support for discovery? There is one other one auth setup function in discovery.c:setup_authentication(). Not sure why we have two almost identical functions there. Probably due to how it is all compiled. Do not worry about the duplication in this patch. We can just fix up discovery.c:setup_authentication(). Yes, we also need to support an empty username for discovery. And I seriously think if we shouldn't redesign the discovery node database: Currently we're storing the _detected_ target names under /etc/iscsi/send_targets, ie we have to preset the CHAP variables in /etc/iscsid.conf. But this makes it impossible to have different settings for different portals; one iSCSI portal might require CHAP authentication discovery, the next might not, and another one might have a different username/password. It would be far more sensible to store the settings for the _portal_ under /etc/iscsi/send_targets, too; this would allow us to modify them via -o update and have different settings for different targets. Can you have a empty incoming username? If so I think we need to modify acl_chap_auth_request like how you did to acl_set_user_name. No, not what I've seen so far; but I haven't been exactly successful here. I'll dig further here. BTW, would it be sensible to support both methods if CHAP is enabled? Currently we're only setting the auth method to either 'CHAP' or 'None'. We means we cannot login to a target which just supports 'None' when we set the record to 'CHAP'. Any specific reason? Methinks it'd be far more sensible to announce 'CHAP,None' whenever CHAP is selected. And to allow login with no credentials, too, in this case. Comments? Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
[PATCH] Allow update of discovery records.
We should allow updating of discovery records, too.
This enables open-iscsi to use different settings during
discovery to different targets.
Signed-off-by: Hannes Reinecke h...@suse.de
diff --git a/usr/idbm.c b/usr/idbm.c
index ee38e64..ca5479e 100644
--- a/usr/idbm.c
+++ b/usr/idbm.c
@@ -2097,6 +2097,35 @@ free_info:
return rc;
}
+int idbm_discovery_set_param(void *data, discovery_rec_t *rec)
+{
+ struct db_set_param *param = data;
+ recinfo_t *info;
+ int rc = 0;
+
+ info = idbm_recinfo_alloc(MAX_KEYS);
+ if (!info)
+ return ENOMEM;
+
+ idbm_recinfo_discovery((discovery_rec_t *)rec, info);
+
+ rc = idbm_verify_param(info, param-name);
+ if (rc)
+ goto free_info;
+
+ rc = idbm_rec_update_param(info, param-name, param-value, 0);
+ if (rc)
+ goto free_info;
+
+ rc = idbm_discovery_write((discovery_rec_t *)rec);
+ if (rc)
+ goto free_info;
+
+free_info:
+ free(info);
+ return rc;
+}
+
int idbm_init(idbm_get_config_file_fn *fn)
{
/* make sure root db dir is there */
diff --git a/usr/idbm.h b/usr/idbm.h
index ed8badd..0609c47 100644
--- a/usr/idbm.h
+++ b/usr/idbm.h
@@ -139,6 +139,7 @@ extern int idbm_rec_read(node_rec_t *out_rec, char
*target_name,
int tpgt, char *addr, int port,
struct iface_rec *iface);
extern int idbm_node_set_param(void *data, node_rec_t *rec);
+extern int idbm_discovery_set_param(void *data, discovery_rec_t *rec);
/* lower level idbm functions for use by iface.c */
extern void idbm_recinfo_config(recinfo_t *info, FILE *f);
diff --git a/usr/iscsiadm.c b/usr/iscsiadm.c
index 9d2ce71..c9f9a88 100644
--- a/usr/iscsiadm.c
+++ b/usr/iscsiadm.c
@@ -1912,7 +1912,7 @@ main(int argc, char **argv)
name, value);
break;
case MODE_DISCOVERY:
- if ((rc = verify_mode_params(argc, argv, SIPdmtplo, 0))) {
+ if ((rc = verify_mode_params(argc, argv, SIPdmntplov, 0))) {
log_error(discovery mode: option '-%c' is not
allowed/supported, rc);
rc = -1;
@@ -1991,6 +1991,19 @@ main(int argc, char **argv)
record!);
rc = -1;
}
+ } else if (op == OP_UPDATE) {
+ struct db_set_param set_param;
+
+ if (!name || !value) {
+ log_error(Update requires
+ name and value);
+ rc = -1;
+ goto out;
+ }
+ set_param.name = name;
+ set_param.value = value;
+ if
(idbm_discovery_set_param(set_param, drec))
+ rc = -1;
} else {
log_error(operation is not
supported.);
rc = -1;
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Resolved: CHAP login with HP mpx100
Hi all, finally I managed to login to a HP mpx100 bridge with CHAP enabled. Turned out that the HP is not using a CHAP username at all, just the password. So we need to tweak open-iscsi to allow empty usernames. Patch to follow. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: SLES10 SP2 x64, two iSCSI targets, I/O hangs
Jeff Q wrote: On Sep 18, 8:54 pm, Mike Christie micha...@cs.wisc.edu wrote: Jeff Q wrote -- with the following repeating pretty frequently: -- Sep 17 13:09:56 afsbackup kernel: ping timeout of 5 secs expired, last rx 4316722054, last ping 4316721118, now 4316724554 Sep 17 13:09:56 afsbackup kernel: connection6:0: iscsi: detected conn error (1011) Sep 17 13:09:56 afsbackup iscsid: semop up failed 22 -- I've read that the semop failed can be resolved if i were to enable CHAP authentication and include the log-in information in the /etc/ iscsi/iscsi.conf file, but I'm trying to take CHAP out of the picture. You can ignore the semop error. It is not related. Any suggestions? Would the newer version of open-iscsi solve the You could just turn off nops. Use these values. node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 I tried this, and it doesn't seem to fix the problem. When I'm logged into both devices, an fdisk -l only shows the more recent of the two. Is there anything I can do to get open-iscsi compiled on SLES10? There has been a backport patch at one point, but this got removed as it conflicted with RHEL. I see to have another one prepared. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: [PATCH] I/O stall finally solved
Mike Christie wrote:
On 08/14/2009 07:01 AM, Hannes Reinecke wrote:
Hi Mike,
finally I've found the mysterious I/O stall I've been chasing
for the last two months.
Problem is iscsi_conn_queue_work(); we're just calling
queue_work() without checking the return value.
However, queue_work() will be effectively a no-op when
there is some work already running, so we'll be missing
quite a few invocations (on my NetApp target I've been
counting up to 12 missed invocations ...).
Huh, I think I am misunderstanding you or I must be misreading workqueue
code or probably both :(
When you saying running do you mean the work fn is running or that the
work is queued (WORK_STRUCT_PENDING bit is set but the work fn is not
yet called)?
I thought this happens when queue_work returns 1:
run_workqueue
work_clear_pending
f(work)
so if we called queue_work while iscsi_data_xmit was running then
queue_work's pending test:
if (!test_and_set_bit(WORK_STRUCT_PENDING, work_data_bits(work))) {
BUG_ON(!list_empty(work-entry));
__queue_work(wq_per_cpu(wq, cpu), work);
would actually queue the work to be run. So I thought we could actually
be getting extra calls to our work function, because we could call
queue_work right after the WORK_STRUCT_PENDING bit cleared but the work
fn is not yet running.
If the queue_work returns 0, then I thought iscsi_data_xmit is not yet
running, so when it does run it would handle the task added to the list
by the caller of queue_work (we do list_add then queue_work so it should
be on the list when the work function would run if the work is pending
when we call queue_work).
Yeah, you are right. My assumptions were too simplistic.
(Read: next time I should read the code more thoroughly ...)
However, I still have the feeling there still is potential
for an I/O stall; this iscsi_check_cmdsn_window_closed() check
simply doesn't feel safe.
Hey, for the list_add+queue_work sequence do I need to add some sort of
barrier?
Not sure; might've as queue_work is potentially run on another CPU.
In addition to that, iscsi_check_cmdsn_window_closed()
doesn't actually check if the cmdsn window has been closed
(in the sense that we're not allowed to send any PDUs),
but rather that the new PDU _to be queued_ will be rejected.
There might still be PDUs in the queue, waiting to be
transferred.
So if we're hitting queuecommand hard enough we might be running into this
scenario:
- iscsi_data_xmit:
Transfers last Data-out PDU in requeue list; all queues are empty.
- xmit_task()
- unlock session
- queuecommand()
being called repeatedly until iscsi_check_cmdsn triggers, giving
xmit thread no chance to grab the session lock
- iscsi_conn_queue_work() does nothing as work is already pending
Yeah, so I thought here because iscsi_data_xmit is running we hit this:
run_workqueue
work_clear_pending
//WORK_STRUCT_PENDING is now cleared so queue_work will queue the work
(queue_work returns 1).
f(work)
But we still will be stuck eg if sendpage() returns a retryable
error other than -EAGAIN.
If such a thing exists. Will have to check.
Anyway, hope to have some more details tomorrow.
Running failover tests against a NetApp Filer.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Re: [PATCH 1/4] libiscsi: Check TMF state before sending PDU
Mike Christie wrote: I think something got dropped by accident when you redid your patchset. There is a missing memset(hdr, 0, sizeof(*hdr)); for iscsi_eh_device_reset. Oh, correct. Will be redoing the patch. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: [PATCH 3/4] libiscsi: Set the 'FINAL' bit to terminate data transfer on TMF
Mike Christie wrote:
On 08/14/2009 01:42 AM, Hannes Reinecke wrote:
Mike Christie wrote:
Hannes Reinecke wrote:
Whenever we send a Data-Out response to an affected LUN during
LU Reset, we should be setting the 'FINAL' bit. This will
indicate to the target that we consider this transfer finished.
Signed-off-by: Hannes Reineckeh...@suse.de
---
drivers/scsi/libiscsi.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index a0d1217..16d35f0 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -321,6 +321,10 @@ static int iscsi_check_tmf_restrictions(struct
iscsi_task *task, int opcode)
task-itt, task-hdr_itt, hdr_lun);
return -EACCES;
}
+/*
+ * Set FINAL flag to terminate data transfer.
+ */
+task-hdr-flags |= ISCSI_FLAG_CMD_FINAL;
Wasn't this in the first patch before?
Yes. But I split it off as it's a different issue.
And this one apparently requires more discussion :-)
The data-out hdr is not prepd yet. The entire thing gets memset'd, so
ORing it does not help.
Yes, and no.
We're hitting this section for Data-Out PDUs only, ie for tasks on the
'requeue' list. All other tasks (for which iscsi_prep_scsi_cmd() would
be called) are filtered out here:
if (opcode != ISCSI_OP_SCSI_DATA_OUT) {
iscsi_conn_printk(KERN_INFO, conn,
as 'opcode' is the parameter passed during invocation, not the actual
opcode of the task.
So the 'FINAL' bit will only be set when we're here:
Yes, it is set there at this time, but we have to prep the data-out pdus
still.
list_for_each_entry_safe(task, tmptask,conn-requeue, running) {
/*
* we always do fastlogout - conn stop code will clean up.
*/
if (conn-session-state == ISCSI_STATE_LOGGING_OUT)
break;
if (iscsi_check_tmf_restrictions(task, ISCSI_OP_SCSI_DATA_OUT))
continue;
conn-task = task;
list_del_init(conn-task-running);
if (conn-task-state == ISCSI_TASK_PENDING)
conn-task-state = ISCSI_TASK_RUNNING;
if (conn-conn_debug)
iscsi_conn_printk(KERN_INFO, conn,
requeue cmdpdu [itt 0x%x cmdsn %u
lun %u] xmit\n, conn-task-itt,
be32_to_cpu(conn-task-cmdsn),
conn-task-sc ?
conn-task-sc-device-lun : -1);
rc = iscsi_xmit_task(conn);
and there we don't do any header prep()ing.
We actually do. We have to prep the data-out pdu/s that get sent. For
tasks on the requeue list the iscsi_xmit_task above we do:
[ Quite detailed explanation skipped ]
You know too, unless this is actually helping your target or any target,
you can probably bury this on the TODO list.
a big Aah
Thanks for the explanation. This was really the missing bit
of information. Until now the R2T transfer code was really a bit
of mystery for me.
Thanks again. So yes, your objections are correct. And we probably
should shelf the 'FINAL' bit on the TODO list; it's going to be
more protracted than originally thought.
So a separate patch was a good idea after all :-)
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Re: [PATCH 1/4] libiscsi: Check TMF state before sending PDU
Mike Christie wrote: Hannes Reinecke wrote: Before we're trying to send a PDU we have to check whether a TMF is active. If so and if the PDU will be affected by the TMF we should allow only Data-out PDUs to be sent, or, if fast_abort is set, no PDUs at all. You sort of changed the behavior of the code and it does not match the description. The fast_abort setting was a hack and not the iscsi RFC one as we discussed before. It used to apply to aborts and lu resets. Now, it only applies to lu resets. I know it's not the RFC one. Only I wasn't quite sure what to do with it for aborts; the current implemented 'fast_abort' logic I deciphered as 'terminate transfer as fast as possible'. So for LU Resets we wouldn't transfer any data to the affected LUN, and for aborts with would just have to block the task with the corresponding itt. Was this intentional? Not really. But was should be done for aborts when fast_abort is set? We only have to block the task with the corresponding itt, no? Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: [PATCH 3/4] libiscsi: Set the 'FINAL' bit to terminate data transfer on TMF
Mike Christie wrote:
Hannes Reinecke wrote:
Whenever we send a Data-Out response to an affected LUN during
LU Reset, we should be setting the 'FINAL' bit. This will
indicate to the target that we consider this transfer finished.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index a0d1217..16d35f0 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -321,6 +321,10 @@ static int iscsi_check_tmf_restrictions(struct
iscsi_task *task, int opcode)
task-itt, task-hdr_itt, hdr_lun);
return -EACCES;
}
+/*
+ * Set FINAL flag to terminate data transfer.
+ */
+task-hdr-flags |= ISCSI_FLAG_CMD_FINAL;
Wasn't this in the first patch before?
Yes. But I split it off as it's a different issue.
And this one apparently requires more discussion :-)
The data-out hdr is not prepd yet. The entire thing gets memset'd, so
ORing it does not help.
Yes, and no.
We're hitting this section for Data-Out PDUs only, ie for tasks on the
'requeue' list. All other tasks (for which iscsi_prep_scsi_cmd() would
be called) are filtered out here:
if (opcode != ISCSI_OP_SCSI_DATA_OUT) {
iscsi_conn_printk(KERN_INFO, conn,
as 'opcode' is the parameter passed during invocation, not the actual
opcode of the task.
So the 'FINAL' bit will only be set when we're here:
list_for_each_entry_safe(task, tmptask, conn-requeue, running) {
/*
* we always do fastlogout - conn stop code will clean up.
*/
if (conn-session-state == ISCSI_STATE_LOGGING_OUT)
break;
if (iscsi_check_tmf_restrictions(task, ISCSI_OP_SCSI_DATA_OUT))
continue;
conn-task = task;
list_del_init(conn-task-running);
if (conn-task-state == ISCSI_TASK_PENDING)
conn-task-state = ISCSI_TASK_RUNNING;
if (conn-conn_debug)
iscsi_conn_printk(KERN_INFO, conn,
requeue cmdpdu [itt 0x%x cmdsn %u
lun %u] xmit\n, conn-task-itt,
be32_to_cpu(conn-task-cmdsn),
conn-task-sc ?
conn-task-sc-device-lun : -1);
rc = iscsi_xmit_task(conn);
and there we don't do any header prep()ing.
Plus you only set the F bit for the final PDU. This would send multiple
PDUs with the final bit set. I think the point of sending a pdu with the
F bit set is that you do not have to send all the data-outs for the
sequence (if a tmf was executing then it does not have to wait for MB of
data). Just send one with the F bit set.
Yes, that was the plan. But I'm not _that_ firm with the R2T code, so
the following argumentation might be wrong.
So, I was under the impression that we're only ever send 1 Data-Out
PDU in response to a R2T. However, there might be more than one
R2T/Data-Out pairs exchanged until the entire data is transferred.
The idea here was that we're setting the 'FINAL' flag for a Data-Out
PDU whenever the data transfer should be stopped.
This _should_ induce the Target to stop sending us R2Ts.
If it does, the transfer is terminated and everyone's happy.
If it doesn't (ie it'll ignore the FINAL flag) we would still
have to send a Data-Out Response.
You want to modify iscsi_prep_data_out_pdu to check if a tmf would
affect that task, and if so then hit the final bit on it. We probably
also want to indicate to the caller that we ended it early so it it can
stop sending more data-outs for that r2t.
Does it make a difference?
When changing iscsi_prep_data_out_pdu() we would be modifying the
header when it's being prep()ed, ie after the SCSI cmd PDU is sent.
But then the task is being rescheduled on the 'requeue' list after
a R2T has been received, and my patch sends the flag just before
it's being sent.
Or am I wrong?
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Re: [RFC] Dynamically adjust shost-can_queue
Mike Christie wrote: Mike Christie wrote: We were discussing this on the fcoe list, and I mentioned it here on the scsi cmd timer patch. What I thought we might want to do is instead of doing it based on cmdsn window rejects which can sometimes be static, we can take into account how often commands are timing while they are still pending. For example if a cmd is still pending and the scsi command timer fires, then can_queue is probably too high at that time. But we probably also need to check the cmdsn window rejects, because I think that can also change on some targets. So it can be separate patches, and I am not against what you are trying to do. Actually, I am not sure what it is buying us except extra complexity just so we can avoid a debug printk. What is the reason for the threshhold code? In your previous patch you just set the can_queue to the cmdsn window size, which seemed fine except the window size could be larger than the number of commands that user had set for node.session.cmds_max. Ah, did I? Totally forgot about this. No, the main reason here was that under heavy loads we're hitting the cmdsn window closed case quite often (the count went into millions, literally). So I thought that it might be better to dynamically modify some setting so that the scsi request_fn could take care of this situation. Which would avoid having to call -queuecommand() unnecessarily, increasing lock contention on the session lock and all that sort of thing. Your're right in that we shouldn't increase above the overall number of commands lest we run into memory problems. We could also then add some code to try and dynamically increase it like Vasu is doing for the device queue_depth. This can_queue rampup would be for the target port resources/limitations instead of Vasu's device one. Oh yeah, just to be clear when I say can_queue I sometimes meant both and sometimes just mean one or the other. The host port can be connected to multiple target ports. Then the target port could be connected to multiple initiator ports. Some of the ports can be on the same target or initiator, but they can also be on completely different boxes, so you end up with both the host and target can_queue limits fluctuating for different reasons. In the end I think you would want to handle both. Yes, definitely. It just so bloody difficult to get to the starget structure. One has to do some traversing starting at the scsi_host, and there are always some locks involved ... bah. A nice clean pointer from iscsi_session to starget would've been nice. So to avoid all this I settled for the host's can_queue; which works as well for open-iscsi. But in general, yes, of course, we should be using starget's can_queue. For the target can_queue you could do something where we never send more than cmdsn window commands, then you could time commands and track if it was taking longer or shorter with different number of commands and you cold track if cmds were timing out, and depending on the results you could increase/decrease the target can_queue similar to what is done with the fc drives and the device queue_depth. The advantage of the simple tracking I've implemented is that it's ... well ... simple. I don't really feel comfortable with tracking the latency of a command, as this depends on various factors. Tracking CmdSN window full rejects solely relies on target properties which is kinda neat, I thought. And I surely do _NOT_ want to track SCSI command timeouts. In most cases these indicate an transport error of some kind and not just a queue overrun. We would want to do something similar for the host can queue too, and then also we will want to hook into Vasu's device queue_depth rampup/down code as well. Also did you try the QUEUE_FULL patch I sent with the MSA target? Yes, I did. But it didn't trigger :-( Not sure on what trigger we should host-can_queue latch on. By rights we should be modifying it based on host parameters. Eg when sendpage() starts returning EAGAIN or somesuch. But currently the target adjusts outweigh any command retries by about 2 orders of magnitude, so it's hardly worth it. Well, for me :-) Might be different when using iSCSI HBAs. Anyway, I'll update the patch. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
[PATCH] I/O stall finally solved
Hi Mike,
finally I've found the mysterious I/O stall I've been chasing
for the last two months.
Problem is iscsi_conn_queue_work(); we're just calling
queue_work() without checking the return value.
However, queue_work() will be effectively a no-op when
there is some work already running, so we'll be missing
quite a few invocations (on my NetApp target I've been
counting up to 12 missed invocations ...).
In addition to that, iscsi_check_cmdsn_window_closed()
doesn't actually check if the cmdsn window has been closed
(in the sense that we're not allowed to send any PDUs),
but rather that the new PDU _to be queued_ will be rejected.
There might still be PDUs in the queue, waiting to be
transferred.
So if we're hitting queuecommand hard enough we might be running into this
scenario:
- iscsi_data_xmit:
Transfers last Data-out PDU in requeue list; all queues are empty.
- xmit_task()
- unlock session
- queuecommand()
being called repeatedly until iscsi_check_cmdsn triggers, giving
xmit thread no chance to grab the session lock
- iscsi_conn_queue_work() does nothing as work is already pending
- iscsi_data_xmit:
- locks session
- returns from xmit_task()
- end of iscsi_data_xmit()
- I/O stall.
So we really should check if we've missed some queue_work calls,
and restart iscsi_data_xmit() if so.
Proposed patch is attached.
Note that in theory we might loop here when -xmit_task() returns
an error. But this loop should be closed as we have had some
changes to the lists as someone called queue_work in the meantime.
Comments etc welcome.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
From 1ab84cdf687ad989a807e0e01fa136601fa3ac2b Mon Sep 17 00:00:00 2001
From: Hannes Reinecke h...@suse.de
Date: Fri, 14 Aug 2009 13:50:15 +0200
Subject: [PATCH] libiscsi: I/O stall under heavy load
When the system is under load we might be missing quite some
invocations to queue_work(). So we need to check at the end
of iscsi_data_xmit() if we've missed some, and, given that
there's still some data in the queue, restart ourselves.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi.c | 16 +++-
include/scsi/libiscsi.h |2 ++
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 0356e3d..75870dd 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -104,8 +104,9 @@ inline void iscsi_conn_queue_work(struct iscsi_conn *conn)
struct Scsi_Host *shost = conn-session-host;
struct iscsi_host *ihost = shost_priv(shost);
- if (ihost-workq)
- queue_work(ihost-workq, conn-xmitwork);
+ if (ihost-workq
+ !queue_work(ihost-workq, conn-xmitwork))
+ set_bit(ISCSI_WORKQUEUE_BIT, conn-suspend_tx);
}
EXPORT_SYMBOL_GPL(iscsi_conn_queue_work);
@@ -1441,6 +1442,7 @@ static int iscsi_data_xmit(struct iscsi_conn *conn)
int rc = 0;
spin_lock_bh(conn-session-lock);
+ clear_bit(ISCSI_WORKQUEUE_BIT, conn-suspend_tx);
if (test_bit(ISCSI_SUSPEND_BIT, conn-suspend_tx)) {
ISCSI_DBG_SESSION(conn-session, Tx suspended!\n);
spin_unlock_bh(conn-session-lock);
@@ -1527,6 +1529,10 @@ check_mgmt:
if (!list_empty(conn-mgmtqueue))
goto check_mgmt;
}
+ /* Check if we've missed workqueue invocations */
+ if (test_bit(ISCSI_WORKQUEUE_BIT, conn-suspend_tx)
+ (!list_empty(conn-cmdqueue) || !list_empty(conn-requeue)) )
+ goto check_mgmt;
spin_unlock_bh(conn-session-lock);
return -ENODATA;
@@ -1895,9 +1901,9 @@ void iscsi_suspend_tx(struct iscsi_conn *conn)
struct Scsi_Host *shost = conn-session-host;
struct iscsi_host *ihost = shost_priv(shost);
+ set_bit(ISCSI_SUSPEND_BIT, conn-suspend_tx);
if (ihost-workq)
flush_workqueue(ihost-workq);
- set_bit(ISCSI_SUSPEND_BIT, conn-suspend_tx);
}
EXPORT_SYMBOL_GPL(iscsi_suspend_tx);
@@ -1956,6 +1962,7 @@ static enum blk_eh_timer_return iscsi_eh_cmd_timed_out(struct scsi_cmnd *sc)
task = (struct iscsi_task *)sc-SCp.ptr;
if (!task)
goto done;
+#if 0
/*
* If we have sent (at least queued to the network layer) a pdu or
* recvd one for the task since the last timeout ask for
@@ -1972,7 +1979,7 @@ static enum blk_eh_timer_return iscsi_eh_cmd_timed_out(struct scsi_cmnd *sc)
rc = BLK_EH_RESET_TIMER;
goto done;
}
-
+#endif
if (!conn-recv_timeout !conn-ping_timeout)
goto done
Re: [PATCH 4/4] libiscsi: Flush workqueue before suspend
Ulrich Windl wrote:
On 13 Aug 2009 at 11:55, Mike Christie wrote:
some additions:
Mike Christie wrote:
wait_on_commands()
{
while (check_restrictions(conn-task)
session-state == LOGGED_IN)
wait for a while
wait for a while always looks like a design flaw to me. Wait for what?
For the xmit thread to catch up. Due to the asynchronous nature the
xmit thread is independent on the error handler thread, so the
eh thread has to be synchronized here until the xmit thread has processed
all outstanding commands.
Tricky, that. And the main reason why I didn't do it, but used the simpler
approach :-)
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
[PATCH 4/4] libiscsi: Flush workqueue before suspend
If 'fast_abort' is not set we should be sending all outstanding Data-out PDUs to the target, even after we have received the tmf response. So we should make sure that the workqueue is really flushed and all PDUs have been processed before setting the 'SUSPEND' bit. Signed-off-by: Hannes Reinecke h...@suse.de --- drivers/scsi/libiscsi.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c index 16d35f0..5606c4d 100644 --- a/drivers/scsi/libiscsi.c +++ b/drivers/scsi/libiscsi.c @@ -1880,9 +1880,9 @@ void iscsi_suspend_tx(struct iscsi_conn *conn) struct Scsi_Host *shost = conn-session-host; struct iscsi_host *ihost = shost_priv(shost); - set_bit(ISCSI_SUSPEND_BIT, conn-suspend_tx); if (ihost-workq) flush_workqueue(ihost-workq); + set_bit(ISCSI_SUSPEND_BIT, conn-suspend_tx); } EXPORT_SYMBOL_GPL(iscsi_suspend_tx); -- 1.6.0.2 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
[PATCH 1/4] libiscsi: Check TMF state before sending PDU
Before we're trying to send a PDU we have to check whether a TMF
is active. If so and if the PDU will be affected by the TMF
we should allow only Data-out PDUs to be sent, or, if
fast_abort is set, no PDUs at all.
Signed-off-by: Mike Christie micha...@cs.wisc.edu
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/libiscsi.c| 112 +++-
include/scsi/iscsi_proto.h |2 +
2 files changed, 102 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index ef08f10..fd34347 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -263,6 +263,88 @@ static int iscsi_prep_bidi_ahs(struct iscsi_task *task)
}
/**
+ * iscsi_check_tmf_restrictions - check if a task is affected by TMF
+ * @task: iscsi task
+ * @opcode: opcode to check for
+ *
+ * During TMF a task has to be checked if it's affected.
+ * All unrelated I/O can be passed through, but I/O to the
+ * affected LUN should be restricted.
+ * If 'fast_abort' is set we won't be sending any I/O to the
+ * affected LUN.
+ * Otherwise the target is waiting for all TTTs to be completed,
+ * so we have to send all outstanding Data-Out PDUs to the target.
+ */
+static int iscsi_check_tmf_restrictions(struct iscsi_task *task, int opcode)
+{
+ struct iscsi_conn *conn = task-conn;
+ struct iscsi_tm *tmf = conn-tmhdr;
+ unsigned int hdr_lun;
+
+ if (conn-tmf_state == TMF_INITIAL)
+ return 0;
+
+ if ((tmf-opcode ISCSI_OPCODE_MASK) != ISCSI_OP_SCSI_TMFUNC)
+ return 0;
+
+ switch (ISCSI_TM_FUNC_VALUE(tmf)) {
+ case ISCSI_TM_FUNC_LOGICAL_UNIT_RESET:
+ /*
+* Allow PDUs for unrelated LUNs
+*/
+ hdr_lun = scsilun_to_int((struct scsi_lun *)tmf-lun);
+ if (hdr_lun != task-sc-device-lun)
+ return 0;
+
+ /*
+* Fail all SCSI cmd PDUs
+*/
+ if (opcode != ISCSI_OP_SCSI_DATA_OUT) {
+ iscsi_conn_printk(KERN_INFO, conn,
+ task [op %x/%x itt
+ 0x%x/0x%x lun %u]
+ rejected.\n,
+ task-hdr-opcode, opcode,
+ task-itt, task-hdr_itt, hdr_lun);
+ return -EACCES;
+ }
+ /*
+* And also all data-out PDUs in response to R2T
+* if fast_abort is set.
+*/
+ if (conn-session-fast_abort) {
+ iscsi_conn_printk(KERN_INFO, conn,
+ task [op %x/%x itt
+ 0x%x/0x%x lun %u]
+ fast abort.\n,
+ task-hdr-opcode, opcode,
+ task-itt, task-hdr_itt, hdr_lun);
+ return -EACCES;
+ }
+ break;
+ case ISCSI_TM_FUNC_ABORT_TASK:
+ /*
+* the caller has already checked if the task
+* they want to abort was in the pending queue so if
+* we are here the cmd pdu has gone out already, and
+* we will only hit this for data-outs
+*/
+ if (opcode == ISCSI_OP_SCSI_DATA_OUT
+ task-hdr_itt == tmf-rtt) {
+ ISCSI_DBG_SESSION(conn-session,
+ Preventing task %x/%x from sending
+ data-out due to abort task in
+ progress\n, task-itt,
+ task-hdr_itt);
+ return -EACCES;
+ }
+ break;
+ }
+
+ return 0;
+}
+
+/**
* iscsi_prep_scsi_cmd_pdu - prep iscsi scsi cmd pdu
* @task: iscsi task
*
@@ -279,6 +361,10 @@ static int iscsi_prep_scsi_cmd_pdu(struct iscsi_task *task)
itt_t itt;
int rc;
+ rc = iscsi_check_tmf_restrictions(task, ISCSI_OP_SCSI_CMD);
+ if (rc)
+ return rc;
+
if (conn-session-tt-alloc_pdu) {
rc = conn-session-tt-alloc_pdu(task, ISCSI_OP_SCSI_CMD);
if (rc)
@@ -1329,6 +1415,7 @@ EXPORT_SYMBOL_GPL(iscsi_requeue_task);
**/
static int iscsi_data_xmit(struct iscsi_conn *conn)
{
+ struct iscsi_task *task;
int rc = 0;
spin_lock_bh(conn-session-lock);
@@ -1366,11 +1453,8 @@ check_mgmt:
/* process pending command queue */
while (!list_empty(conn-cmdqueue)) {
- if (conn-tmf_state == TMF_QUEUED)
- break;
-
- conn-task = list_entry(conn-cmdqueue.next
[PATCH 0/4] Update LU Reset handling (take #2)
Hi Mike, these is my second stab at the LU Reset handling update. The first patch implements the 'iscsi_check_tmf_restrictions' function, which allows us to filter out individual PDUs which should not be send. The other patches are merely for improving LU Reset handling when 'fast_abort' is not set. In this case we should be sending all outstanding data-out PDUs to the target. However, with the current list traversal of while(!list_empty()) for the 'requeue' list we will break out on the first PDU for which tmf restriction check triggers. This will cause all other PDUs in the list not to be checked. So the first patch changes this to a 'normal' list traversal with 'list_for_each', which will process all PDUs. The second patch just sets the 'FINAL' bit for Data-out PDUs to terminate the transfer. And the third patch is flushing the workqueue _before_ the SUSPEND bit is set; otherwise iscsi_data_xmit() will be short-circuited by the SUSPEND-bit set, causing any data still queued not to be send. One thing I'm not quite sure yet: What are the contents of the 'requeue' list? Will that only be 'DATA-Out' PDUs? If so, then the last patch should be irrelevant as the 'requeue' list will be flushed anyway. If not, then the first and the third patch should be modified. The first should filter out Data-Out PDUs, but in realiter it just checks which queue is being used. So if the 'requeue' list contains non-Data-Out PDUs this check is clearly bogus. Similar goes for the third patch; the FINAL bit really makes sense only for Data-Out PDUs to be set; for normal SCSI cmd PDUs the FINAL bit has a different meaning and will induce a protocol error. As for the 'incomplete PDU' handling; we might be able to catch this by updating the second patch. Instead of breaking out of the loop we can just continue when an error occurred; this way we make sure that we're processing all outstanding PDUs. Those which failed will get processed by the next call to data_xmit(); assuming it was a transient error we should be able to process them. Of course, no guarantees there. The proper way would be to check the possible return codes and only break out on the non-retryable ones only, but continue for others. Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Re: [PATCH 5/5] libiscsi: Flush workqueue before suspend
Mike Christie wrote:
On 08/07/2009 05:27 AM, Hannes Reinecke wrote:
We should be flushing the workqueue before setting the suspend
bit. If we don't a LU Reset might kill commands which are already
in the queue and waiting to be send, causing the target to barf.
What do you mean here? What do you mean by barf? What commands in what
queue?
In the 'requeue' queue. There might be Data-out requests still waiting
to be sent, but we can't as the xmit thread would be short-circuited
as we've set the SUSPEND bit.
Are you talking about the problem where we get a tmf response, and do
not send data-outs? If so this will not always help. The data-out could
be on the wire and the target could still hit the problem. The problem
is not ours. The target should not send a tmf response that indicates it
was successful if there is a r2t that is in progress of being fullfilled.
That is a matter of interpretation. The targets seem to implement the wording
of RFC5048, section 4.1.2:
The target iSCSI layer:
- MUST wait for responses on currently valid target-transfer tags of the
affected tasks from the issuing initiator.
So, a 'wait' clearly indicates some sort of timer on the target side.
However, what should be the response if not all ttt are being received
from the initiator?
From what I've gathered, the MSA target in this case will return a
TMF response even when not all data-outs have been received, and
after a certain time will drop the connection to trigger ERL0.
Basically, all I'm trying to do is to run this test-case:
(bonnie/dt on all devices)
for d in /sys/bus/sd*; do
sg_reset -d /dev/${file##*/}
done
The result of this test run is that in ca 90% sg_reset will
run through, but the other 10% cause a full ERL0.
And I'm trying to determine the reason for this pecularity.
Weird, though, that apparently I'm hitting quite a bunch
of issues here ...
Or...
Are you talking about if we have task 0 and task 1 in progress, then
send a lu reset that should affect those two tasks, but then we get a
task2 in the cmdqueue list, and then we get a tmf response, so we end up
cleaning up task0, task1 and task2? If so, how does the target barf here
(is it a connection drop or some error because the task does not get sent)?
Hmm. Checking ...
No, I won't be sending any other SCSI command PDU to the affected LUN; that's
being blocked by the check_tmf_restrictions() function.
If this is your problem, then your patch would work under normal
conditions, but if you have sndtmo=1 then you could still hit this
problem a little more easily than normal. If the sendpage code returned
EAGAIN (which gets converted to ENOBUFS in your patch) due to the sndtmo
then we will return from
iscsi_data_xmit without completely sending the task or any task behind
it (if there was also a task3 queued).
We could also hit the problem, where if task0 was affected by a TMF then
iscsi_data_xmit returns EACCESS. Then task2 is not going to get sent,
because it is stuck behind task0 on the cmdlist. I think in the patches
[PATCH 1/5] libiscsi: Allow multiple LUN Reset TMF
[PATCH 2/5] Check for TMF state before sending PDU
you need to also modify conn-tmf_state and clear the conn-tmf header
before suspending the xmit thread.
I was thinking about this the other day and I think we can jsut add a
check in fail_scsi_task to check for tasks with a cmdsn less than the lu
reset cmd's cmdsn, right? Maybe we want to fail the affected tasks with
DID_ERROR, but then for the non-affected tasks we could fail with
DID_IMM_RETRY. So then if this was a reset from something like sg_reset
those tasks that were not affected would get another full timeout period
to run in case the lu reset took a long time.
I actually thought about the same lines, and even added some CmdSn printks.
However, the CmdSn of running task is not getting updated, so currently
these are quite pointless. But I can see what I'm getting.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
