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 is
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(&ihost->mutex);
- ihost->netns = &init_net;
+ if (transport->get_netns)
+ ihost->netns = transport->get_netns(shost);
+ else
+ ihost->netns = &init_net;
iscsi_bsg_host_add(shost, ihost);
/* ignore any bsg add error - we just can't do sgio */
diff --git a/include/scsi/scsi_transport_iscsi.h
b/include/scsi/scsi_transport_iscsi.h
index 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(&rx_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, &group);
+ err = iscsi_if_recv_msg(net, skb, nlh, &group);
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(&qedi->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 = &iscsi_endpoint_class;
+ ep->dev.parent = &shost->shost_gendev;
dev_set_name(&ep->dev, "ep-%d", id);
err = device_register(&ep->dev);
if (err)
Umm... doesn't this change the sysfs layout?
IE won't the endpoint node
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: [PATCH 0/7] Enable iSCSI offload drivers to use information from iface.
On 06/06/2017 08:07 PM, Robert LeBlanc wrote: > This patchset enables iSCSI offload drivers to have access to the iface > information provided by iscsid. This allows users to have more control > of how the driver connects to the iSCSI target. iSER is updated to use > iface.ipaddress to set the source IP address if configured. This allows > iSER to use multiple ports on the same network or in more complicated > routed configurations. > > Since there is already a change to the function parameters, dst_addr > is upgraded to sockaddr_storage so that it is more future proof and makes > the size of the struct static and not dependent on checking the SA_FAMILY. > > This is dependent on updates to Open-iSCSI. > > Robert LeBlanc (7): > scsi/scsi_transport_iscsi: Add iface struct to kernel. > scsi/scsi_transport_iscsi: Update ep_connect to include iface. > ib/iSER: Add binding to source IP address. > scsi/be2iscsi: Update beiscsi_ep_connect to accept iface and > sockaddr_storage. > scsi/bnx2i: Update bnx2i_ep_connect to accept iface and > sockaddr_storage. > scsi/cxgbi: Update cxgbi_ep_connect to accept iface and > sockaddr_storage. > scsi/qla4xxx: Update qla4xxx_ep_connect to accept iface and > sockaddr_storage. > > drivers/infiniband/ulp/iser/iscsi_iser.c | 33 +++-- > drivers/infiniband/ulp/iser/iscsi_iser.h | 4 +- > drivers/infiniband/ulp/iser/iser_initiator.c | 1 + > drivers/infiniband/ulp/iser/iser_memory.c| 1 + > drivers/infiniband/ulp/iser/iser_verbs.c | 8 ++- > drivers/scsi/be2iscsi/be_cmds.c | 1 + > drivers/scsi/be2iscsi/be_iscsi.c | 8 ++- > drivers/scsi/be2iscsi/be_iscsi.h | 5 +- > drivers/scsi/be2iscsi/be_main.c | 1 + > drivers/scsi/be2iscsi/be_mgmt.c | 1 + > drivers/scsi/bnx2i/bnx2i_hwi.c | 1 + > drivers/scsi/bnx2i/bnx2i_iscsi.c | 13 ++-- > drivers/scsi/cxgbi/libcxgbi.c| 15 ++-- > drivers/scsi/cxgbi/libcxgbi.h| 2 +- > drivers/scsi/qla4xxx/ql4_os.c| 15 ++-- > drivers/scsi/scsi_transport_iscsi.c | 9 ++- > include/scsi/scsi_transport_iscsi.h | 100 > ++- > 17 files changed, 179 insertions(+), 39 deletions(-) > Hmm. That it rather large, just for passing information from userspace into the kernel. What is the actual benefit here? Personally, I would rather see iscsid creating tap interfaces associated with each iSCSI offload interface, and having the kernel accessing the information from _that_. Then each connection would have a network interface attached to it, and could retrieve the information from there. Plus we could use 'normal' userspace tools like 'ip' to configure the iSCSI offload network. 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: [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 > <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(&pfd, 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
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
---
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_
Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers
On 09/27/2016 03:50 AM, The Lee-Man wrote: > Christoph Hellwig suggested we do away with the open-iscsi google group > (this group) and use linux-scsi. > > Any thoughts on this? (removed others on the cc list). > Well, there still _is_ a reason to have a list for discussing open-iscsi userland. We have a similar situation on dm-devel, which is used to discuss both the kernel side (ie drivers/md/dm-*) and the userspace tooling. But I'm not really in favour of that; it's occasionally confusing if a particular post relies to the kernel or userland. So I'm more in favour to use linux-scsi for the kernel-related stuff and keep another group (like this one) for userland tools. 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: [PATCH 1/3] scsi_transport_iscsi: Add stats support for iscsi host
TIMEOUT_ERR;
>> +else if (attr == &dev_attr_host_format_err.attr)
>> +param = ISCSI_HOST_PARAM_FORMAT_ERR;
>> +else if (attr == &dev_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 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(&attr); >>> pthread_attr_setstacksize(&attr, PTHREAD_STACK_MIN); >>> pthread_create(..., &attr, ..., ...); >> >> 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(&attr); > pthread_attr_setstacksize(&attr, PTHREAD_STACK_MIN); > pthread_create(..., &attr, ..., ...); > 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: [PATCH] remove sysfs attr_list
On 02/20/2016 03:41 AM, Chris Leech wrote: > On Thu, Feb 18, 2016 at 06:18:07PM -0600, Mike Christie wrote: >> On 02/17/2016 05:01 PM, Chris Leech wrote: >>> The global cache is not well designed, it quickly can grow to the point >>> where lookups take much longer than just doing the sysfs read in the >>> first place. >> >> Patch looks good. Thanks for working on this. >> >> Is the device cache not as a issue because there are a lot fewer >> devices/cache entries, or because we just to not go down that code path >> as often? > > More of the second I think. It doesn't pop up in a CPU profile, as > session login seems to be dominated by dominated by a mix of VFS > syscalls (mostly stat, lstat and open) now. > > There's a bit of a memory footprint hit for it, more significant to > iscsiadm than iscsid which has much bigger memory costs. With a bit of > testing to ensure it doesn't degrade anything it can probably be removed > as well. > Aah. That triggers bad memories. 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. 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: sysfs handling improvements for large number of sessions
On 02/18/2016 12:01 AM, Chris Leech wrote: This is in response to the previous discussions about login times when scaling out to thousands of sessions. I'm still looking at converting to libudev, but it's going to be a big enough change that I thought it might make sense to just remove the attr_list on it's own first. Sysfs paths are rarely re-read without clearing the list first anyway, and after a few hundred sessions operations become CPU bound on doing strcmp against every item in the list. Watchout when converting to libudev. The attributes read via libudev are cached, so you won't be getting any updates. Caused me grief without end for multipathing. In the end I wrote my own wrappers for attributes which may change on the fly. 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" >> Signed-off-by: Suman Anna > > 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 --- 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-pc] [LSF/MM TOPIC] iSCSI MQ adoption via MCS discussion
On 01/09/2015 07:00 PM, Michael Christie wrote: > > On Jan 8, 2015, at 11:03 PM, Nicholas A. Bellinger > wrote: > >> On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote: >>> On Thu, 2015-01-08 at 14:57 -0800, Nicholas A. Bellinger wrote: >>>> On Thu, 2015-01-08 at 14:29 -0800, James Bottomley wrote: >>>>> On Thu, 2015-01-08 at 14:16 -0800, Nicholas A. Bellinger wrote: >> >> >> >>>> The point is that a simple session wide counter for command sequence >>>> number assignment is significantly less overhead than all of the >>>> overhead associated with running a full multipath stack atop multiple >>>> sessions. >>> >>> I don't see how that's relevant to issue speed, which was the measure we >>> were using: The layers above are just a hopper. As long as they're >>> loaded, the MQ lower layer can issue at full speed. So as long as the >>> multipath hopper is efficient enough to keep the queues loaded there's >>> no speed degradation. >>> >>> The problem with a sequence point inside the MQ issue layer is that it >>> can cause a stall that reduces the issue speed. so the counter sequence >>> point causes a degraded issue speed over the multipath hopper approach >>> above even if the multipath approach has a higher CPU overhead. >>> >>> Now, if the system is close to 100% cpu already, *then* the multipath >>> overhead will try to take CPU power we don't have and cause a stall, but >>> it's only in the flat out CPU case. >>> >>>> Not to mention that our iSCSI/iSER initiator is already taking a session >>>> wide lock when sending outgoing PDUs, so adding a session wide counter >>>> isn't adding any additional synchronization overhead vs. what's already >>>> in place. >>> >>> I'll leave it up to the iSER people to decide whether they're redoing >>> this as part of the MQ work. >>> >> >> Session wide command sequence number synchronization isn't something to >> be removed as part of the MQ work. It's a iSCSI/iSER protocol >> requirement. >> >> That is, the expected + maximum sequence numbers are returned as part of >> every response PDU, which the initiator uses to determine when the >> command sequence number window is open so new non-immediate commands may >> be sent to the target. >> >> So, given some manner of session wide synchronization is required >> between different contexts for the existing single connection case to >> update the command sequence number and check when the window opens, it's >> a fallacy to claim MC/S adds some type of new initiator specific >> synchronization overhead vs. single connection code. > > I think you are assuming we are leaving the iscsi code as it is today. > > For the non-MCS mq session per CPU design, we would be allocating and > binding the session and its resources to specific CPUs. They would only > be accessed by the threads on that one CPU, so we get our > serialization/synchronization from that. That is why we are saying we > do not need something like atomic_t/spin_locks for the sequence number > handling for this type of implementation. > Wouldn't that need to be coordinated with the networking layer? Doesn't it do the same thing, matching TX/RX queues to CPUs? If so, wouldn't we decrease bandwidth by restricting things to one CPU? 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: [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: Target Portal Group tag usage in iscsistart
On 06/30/2014 07:16 PM, Mike Christie wrote: On 06/30/2014 11:34 AM, Mike Christie wrote: On 06/30/2014 04:43 AM, Hannes Reinecke wrote: Hi Mike, iscsistart has the Target Portal Group Tag (tpgt) set to 'required', ie without specifying it iscsistart won't attempt to connect to the target. Now as we're not supporting MC/S anyway, the usage of tpgt is pretty much defined by the target, ie we should be using whatever the target presents to us. And there is no way of specifying the tpgt when using DHCP; RFC4173 doesn't know about this and consequently doesn't specify it. Can't we get rid of the mandatory usage in iscsistart and have it use the target-provided tpgt? Yes. The login.c code was modified to not require the tpgt, but I am not sure why I never fixed iscsistart.c. If you have a patch send it. If not then I just removed the tpgt check from check_params and I will test it later today. The attached patch works for me. Hmm. _That_ I could've done myself :-) Nevertheless, I'll be testing it. Thanks. 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.
Target Portal Group tag usage in iscsistart
Hi Mike, iscsistart has the Target Portal Group Tag (tpgt) set to 'required', ie without specifying it iscsistart won't attempt to connect to the target. Now as we're not supporting MC/S anyway, the usage of tpgt is pretty much defined by the target, ie we should be using whatever the target presents to us. And there is no way of specifying the tpgt when using DHCP; RFC4173 doesn't know about this and consequently doesn't specify it. Can't we get rid of the mandatory usage in iscsistart and have it use the target-provided tpgt? 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
---
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.
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.
[PATCH] Add missing DESTDIR
From: Lee Duncan Several Makefile targets are missing DESTDIR, making it hard for packagers. Signed-off-by: Lee Duncan Signed-off-by: Hannes Reinecke --- 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.
[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 --- 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 0/2] iscsiuio: update autoconf
Hi Eddie, as discussed here is a patchset to remove the auto-generated files from tracking. And I've updated the autoconf files so the current autoreconf doesn't complain. Hannes Reinecke (2): iscsiuio: Remove autogenerated files from tracking iscsiuio: Update automake files Makefile | 3 + iscsiuio/Makefile.in | 629 - iscsiuio/aclocal.m4 | 7276 - iscsiuio/compile | 142 - iscsiuio/config.guess| 1548 -- iscsiuio/config.h.in | 111 - iscsiuio/config.status | 1236 -- iscsiuio/config.sub | 1695 -- iscsiuio/configure | 24269 - iscsiuio/configure.ac| 4 +- iscsiuio/depcomp | 589 - iscsiuio/install-sh | 519 - iscsiuio/ltmain.sh | 6912 iscsiuio/missing | 367 - iscsiuio/src/Makefile.in | 471 - iscsiuio/src/apps/Makefile.in| 471 - iscsiuio/src/apps/brcm-iscsi/Makefile.am | 2 +- iscsiuio/src/apps/brcm-iscsi/Makefile.in | 446 - iscsiuio/src/apps/dhcpc/Makefile.am | 2 +- iscsiuio/src/apps/dhcpc/Makefile.in | 461 - iscsiuio/src/uip/Makefile.am | 2 +- iscsiuio/src/uip/Makefile.in | 562 - iscsiuio/src/unix/Makefile.am| 2 +- iscsiuio/src/unix/Makefile.in| 767 - iscsiuio/src/unix/build_date.c | 1 - iscsiuio/src/unix/build_date.h | 1 - iscsiuio/src/unix/libs/Makefile.am | 2 +- iscsiuio/src/unix/libs/Makefile.in | 450 - iscsiuio/stamp-h1| 1 - 29 files changed, 10 insertions(+), 48931 deletions(-) delete mode 100644 iscsiuio/Makefile.in delete mode 100644 iscsiuio/aclocal.m4 delete mode 100755 iscsiuio/compile delete mode 100755 iscsiuio/config.guess delete mode 100644 iscsiuio/config.h.in delete mode 100755 iscsiuio/config.status delete mode 100755 iscsiuio/config.sub delete mode 100755 iscsiuio/configure delete mode 100755 iscsiuio/depcomp delete mode 100755 iscsiuio/install-sh delete mode 100755 iscsiuio/ltmain.sh delete mode 100755 iscsiuio/missing delete mode 100644 iscsiuio/src/Makefile.in delete mode 100644 iscsiuio/src/apps/Makefile.in delete mode 100644 iscsiuio/src/apps/brcm-iscsi/Makefile.in delete mode 100644 iscsiuio/src/apps/dhcpc/Makefile.in delete mode 100644 iscsiuio/src/uip/Makefile.in delete mode 100644 iscsiuio/src/unix/Makefile.in delete mode 100644 iscsiuio/src/unix/build_date.c delete mode 100644 iscsiuio/src/unix/build_date.h delete mode 100644 iscsiuio/src/unix/libs/Makefile.in delete mode 100644 iscsiuio/stamp-h1 -- 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 2/2] iscsiuio: Update automake files
The automake files from iscsiuio are somewhat oldish.
So update them to the current standard.
Signed-off-by: Hannes Reinecke
---
Makefile | 3 +++
iscsiuio/configure.ac| 4 ++--
iscsiuio/src/apps/brcm-iscsi/Makefile.am | 2 +-
iscsiuio/src/apps/dhcpc/Makefile.am | 2 +-
iscsiuio/src/uip/Makefile.am | 2 +-
iscsiuio/src/unix/Makefile.am| 2 +-
iscsiuio/src/unix/libs/Makefile.am | 2 +-
7 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index 0b7bb98..1d9bc11 100644
--- a/Makefile
+++ b/Makefile
@@ -49,6 +49,9 @@ utils/open-isns/Makefile: utils/open-isns/configure
utils/open-isns/Makefile.in
iscsiuio/Makefile: iscsiuio/configure iscsiuio/Makefile.in
cd iscsiuio; ./configure
+iscsiuio/configure: iscsiuio/configure.ac
+ cd iscsiuio; autoreconf
+
kernel: force
$(MAKE) -C kernel
@echo "Kernel Compilation complete Output file"
diff --git a/iscsiuio/configure.ac b/iscsiuio/configure.ac
index 381b94d..4faee9e 100644
--- a/iscsiuio/configure.ac
+++ b/iscsiuio/configure.ac
@@ -13,9 +13,9 @@ dnl
PACKAGE=iscsiuio
VERSION=0.7.8.2
-AC_INIT(iscsiuio, 0.7.8.2, eddie@broadcom.com)
+AC_INIT([iscsiuio], [0.7.8.2], [eddie@broadcom.com])
-AM_INIT_AUTOMAKE($PACKAGE, $VERSION)
+AM_INIT_AUTOMAKE
AC_CONFIG_HEADER(config.h)
AC_PATH_PROGS(BASH, bash)
diff --git a/iscsiuio/src/apps/brcm-iscsi/Makefile.am
b/iscsiuio/src/apps/brcm-iscsi/Makefile.am
index fb4d661..00cbd8e 100644
--- a/iscsiuio/src/apps/brcm-iscsi/Makefile.am
+++ b/iscsiuio/src/apps/brcm-iscsi/Makefile.am
@@ -1,4 +1,4 @@
-INCLUDES = -I${top_srcdir}/src/unix\
+AM_CFLAGS =-I${top_srcdir}/src/unix\
-I${top_srcdir}/src/uip \
-I${top_srcdir}/src/apps/dhcpc \
-I${top_srcdir}/src/apps/brcm-iscsi \
diff --git a/iscsiuio/src/apps/dhcpc/Makefile.am
b/iscsiuio/src/apps/dhcpc/Makefile.am
index b8a7bbf..1c97993 100644
--- a/iscsiuio/src/apps/dhcpc/Makefile.am
+++ b/iscsiuio/src/apps/dhcpc/Makefile.am
@@ -1,4 +1,4 @@
-INCLUDES = -I${top_srcdir}/src/unix\
+AM_CFLAGS =-I${top_srcdir}/src/unix\
-I${top_srcdir}/src/uip \
-I${top_srcdir}/src/apps/dhcpc \
-I${top_srcdir}/src/apps/brcm-iscsi \
diff --git a/iscsiuio/src/uip/Makefile.am b/iscsiuio/src/uip/Makefile.am
index 2d20573..65c1286 100644
--- a/iscsiuio/src/uip/Makefile.am
+++ b/iscsiuio/src/uip/Makefile.am
@@ -1,4 +1,4 @@
-INCLUDES = -I${top_srcdir}/src/unix\
+AM_CFLAGS =-I${top_srcdir}/src/unix\
-I${top_srcdir}/src/apps/dhcpc \
-I${top_srcdir}/src/apps/brcm-iscsi \
-I${top_srcdir}/../include \
diff --git a/iscsiuio/src/unix/Makefile.am b/iscsiuio/src/unix/Makefile.am
index ef853a7..898691d 100644
--- a/iscsiuio/src/unix/Makefile.am
+++ b/iscsiuio/src/unix/Makefile.am
@@ -1,6 +1,6 @@
SUBDIRS= libs
-INCLUDES = -I${top_srcdir}/src/uip \
+AM_CFLAGS = -I${top_srcdir}/src/uip\
-I${top_srcdir}/src/apps/brcm-iscsi \
-I${top_srcdir}/src/apps/dhcpc \
-I${top_srcdir}/src/unix/libs\
diff --git a/iscsiuio/src/unix/libs/Makefile.am
b/iscsiuio/src/unix/libs/Makefile.am
index 19a1323..890415f 100644
--- a/iscsiuio/src/unix/libs/Makefile.am
+++ b/iscsiuio/src/unix/libs/Makefile.am
@@ -1,4 +1,4 @@
-INCLUDES = -I${top_srcdir}/src/uip \
+AM_CFLAGS = -I${top_srcdir}/src/uip\
-I${top_srcdir}/src/unix \
-I${top_srcdir}/src/unix/libs\
-I${top_srcdir}/src/apps/dhcpc \
--
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: [PATCH 5/5] ISCSIUIO: Updated the configure file to reflect the new version
On 12/23/2013 07:38 PM, Mike Christie wrote: > On 12/23/2013 12:12 PM, Eddie Wai wrote: >> On Mon, 2013-12-23 at 02:35 -0600, Mike Christie wrote: >>> On 12/11/2013 05:38 PM, Eddie Wai wrote: >>>> Signed-off-by: Eddie Wai >>>> --- >>>> iscsiuio/configure |11348 >>>> +--- >>>> 1 files changed, 6426 insertions(+), 4922 deletions(-) >>> >>> Patches look fine. Only problem is that for this one it did not apply >>> cleanly. I got the attached rejects. >> Thanks for applying the patches, Mike. >> >> I just re-cloned your tree from github and still was not able to see the >> aforementioned patch conflict. Perhaps there's a different code base >> that I should fetch from? Thanks. >> > > Can you resend the patch as an attachment? > Where is the point of this patch? 'configure' is auto-generated from 'configure.ac'. And is likely to change, depending on the machine/system/OS you're generating it at. Please remove it from tracking. 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.
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 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 Reinecke 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 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: [PATCH] open-iscsi-synchronize-startup-settings
On 08/17/2011 02:07 PM, s...@i3.noreply.com wrote: From e7e8d62b02361c05e857cd87a68855725c3a72c7 Mon Sep 17 00:00:00 2001 From: Hannes Reinecke Date: Fri, 17 Jul 2009 16:00:39 +0200 Subject: [PATCH] Synchronize startup settings The iscsi node settings contain two 'startup' settings, one for the node and one for the connection. However, as MC/S is not supported both settings have the same effect. And if both of them are set differently the --loginall and --logoutall code will match against _both_, leading to erratic behaviour. So we should make sure that both of them are always in synch to avoid these errors. References: bnc#514273 Signed-off-by: Hannes Reinecke Hmph. It would've been nice if you at least would have informed me that you're upstreaming my patches. Actually I did work on pushing these upstream; if they are not it's for a reason ... Just taking my patches blindly is probably _not_ a good idea. 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
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.
ipaddress host param
Hi all, trying to figure out why my be2iscsi thing doesn't work I've came across this: # cat /sys/class/iscsi_host/host5/ipaddress cat: /sys/class/iscsi_host/host5/ipaddress: Function not implemented Reason being here that be2iscsi sets this mask: .host_param_mask = ISCSI_HOST_HWADDRESS | ISCSI_HOST_IPADDRESS | ISCSI_HOST_INITIATOR_NAME, but doesn't have a callback for the IP address. Not being utterly familiar with be2iscsi I would guess it'd need an IP address, seeing that it's using it's own PCI device. So I would've thought it should have a callback, too. 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 Reinecke
---
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 8/8] boot.suse: Update with latest fixes
Include latest fixes from SUSE.
Signed-off-by: Hannes Reinecke
---
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.
[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
---
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" = "" ] && 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" = "" ] && ifname=
+
+echo $ifname
+}
+
+iscsi_get_ipaddr_from_iface()
+{
+local iface=$1
+local ipaddr
+
+ipaddr=$(iscsiadm -m iface -I "$iface" 2> /
[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
---
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 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
---
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_ROOT"initiatorname.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 4/8] Keep startup mode in sync when specified in config file
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 Reinecke
---
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);
+ }
}
/*
--
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
---
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 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
---
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 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
---
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 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] 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
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] 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
diff --git a/utils/fwparam_ibft/fwparam_ibft_sysfs.c
b/utils/fwparam_ibft/fwparam_ibft_sysfs.c
index 98e29a6..e44460d 100644
--- a/utils/fwparam_ibft/fwparam_ibft_sysfs.c
+++ b/utils/fwparam_ibft/fwparam_ibft_sysfs.c
@@ -80,7 +80,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;
@@ -95,8 +95,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", 3))
+ if (!strcmp(dent->d_name, ".") || !strcmp(dent->d_name, ".."))
continue;
if (!strncmp(dent->d_name, "net:", 4)) {
@@ -112,17 +111,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);
--
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=
>> $ 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
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
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
#include
#include
+#include
+#include
#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 i
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: 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.
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: Antw: Re: Q: RAID1 with open-iscsi
Mike Christie wrote: > Hey again Hannes, > > On 10/08/2010 01:34 AM, Ulrich Windl wrote: >>>>> Mike Christie schrieb am 08.10.2010 um 05:07 in >> Nachricht<4cae8b0a.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: detected conn error (1011)
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 have put some test kernels at http://beta.suse.com/private/hare/sles11/iscsi Can you test with them and check if this issue is solved? Thanks. 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: 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: 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 > ... > > # 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: [PATCH] Allow empty username for CHAP
Mike Christie wrote: > On 10/02/2009 02:33 AM, Hannes Reinecke wrote: >> I would go with this option for a start. We really should aim for >> making iscsiadm to be as flexible as possible, up to the point where >> iscsid.conf really just sets some sensible defaults; everything else >> should be tweaked via calls to iscsiadm. >> >> And I doubt the change in the default behaviour is really noticeable; >> any user seriously using CHAP with different values will benefit from >> this. >> >> Patch is actually quite simple :-) >> >> --- a/usr/iscsiadm.c >> +++ b/usr/iscsiadm.c >> @@ -2211,12 +2211,12 @@ main(int argc, char **argv) >> rc = -1; >> goto out; >> } >> - >> - memset(&drec, 0, sizeof(discovery_rec_t)); > > The patch does not apply. Upstream does not have this memset. The > attached which should fix that and also changes the docs to relfect that > passing op=update during discovery would update the node records and the > discovery one. With your patch it will only update the node records. > Yes, your patch looks better than mine. As usual :-) 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 -~--~~~~--~~--~--~---
