iscsi: respond to netlink with unicast when appropriate
Subsystems (4)
Chris Leech
maintainerPATCH 1/1 iscsi: respond to netlink with unicast when appropriate
Instead of always multicasting responses, send a unicast netlink message directed at the correct pid. This will be needed if we ever want to support multiple userspace processes interacting with the kernel over iSCSI netlink simultaneously. Limitations can currently be seen if you attempt to run multiple iscsistart commands in parallel.
We've fixed up the userspace issues in iscsistart that prevented multiple instances from running, so now attempts to speed up booting by bringing up multiple iscsi sessions at once in the initramfs are just running into misrouted responses that this fixes.
--- drivers/scsi/scsi_transport_iscsi.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-)
drivers/scsi/scsi_transport_iscsi.c +18 -11
@@ -2322,6 +2322,12 @@ iscsi_multicast_skb(struct sk_buff *skb, uint32_t group, gfp_t gfp)return nlmsg_multicast (nls, skb,0 , group, gfp); } +static int +iscsi_unicast_skb (struct sk_buff *skb,u32 portid) +{ +return nlmsg_unicast (nls, skb, portid); +} +int iscsi_recv_pdu (struct iscsi_cls_conn *conn,struct iscsi_hdr *hdr,char *data,uint32_t data_size) {
@@ -2524,14 +2530,11 @@ void iscsi_ping_comp_event(uint32_t host_no, struct iscsi_transport *transport,EXPORT_SYMBOL_GPL (iscsi_ping_comp_event);static int -iscsi_if_send_reply (uint32_t group,int seq,int type,int done,int multi, -void *payload,int size) +iscsi_if_send_reply (u32 portid,int type,void *payload,int size) {struct sk_buff *skb;struct nlmsghdr *nlh;int len =nlmsg_total_size (size); -int flags = multi ?NLM_F_MULTI :0 ; -int t = done ?NLMSG_DONE : type; skb =alloc_skb (len,GFP_ATOMIC );if (!skb) {
@@ -2539,10 +2542,9 @@ iscsi_if_send_reply(uint32_t group, int seq, int type, int done, int multi,return -ENOMEM ; } - nlh =__nlmsg_put (skb,0 ,0 , t, (len -sizeof (*nlh)),0 ); - nlh->nlmsg_flags = flags; + nlh =__nlmsg_put (skb,0 ,0 , type, (len -sizeof (*nlh)),0 );memcpy (nlmsg_data (nlh), payload, size); -return iscsi_multicast_skb (skb, group,GFP_ATOMIC ); +return iscsi_unicast_skb (skb, portid); } static int
@@ -3470,6 +3472,7 @@ static int iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group) { int err = 0; +u32 portid;struct iscsi_uevent *ev =nlmsg_data (nlh);struct iscsi_transport *transport =NULL ;struct iscsi_internal *priv;
@@ -3490,10 +3493,12 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)if (!try_module_get (transport->owner))return -EINVAL ; + portid =NETLINK_CB (skb).portid; +switch (nlh->nlmsg_type) {case ISCSI_UEVENT_CREATE_SESSION : err =iscsi_if_create_session (priv, ep, ev, -NETLINK_CB (skb).portid, + portid, ev->u.c_session.initial_cmdsn, ev->u.c_session.cmds_max, ev->u.c_session.queue_depth);
@@ -3506,7 +3511,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group) } err =iscsi_if_create_session (priv, ep, ev, -NETLINK_CB (skb).portid, + portid, ev->u.c_bound_session.initial_cmdsn, ev->u.c_bound_session.cmds_max, ev->u.c_bound_session.queue_depth);
@@ -3664,6 +3669,8 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)static void iscsi_if_rx (struct sk_buff *skb) { +u32 portid =NETLINK_CB (skb).portid; +mutex_lock (&rx_queue_mutex);while (skb->len >=NLMSG_HDRLEN ) {int err;
@@ -3699,8 +3706,8 @@ iscsi_if_rx(struct sk_buff *skb)break ;if (ev->type ==ISCSI_UEVENT_GET_CHAP && !err)break ; - err =iscsi_if_send_reply (group, nlh->nlmsg_seq, - nlh->nlmsg_type,0 ,0 , ev,sizeof (*ev)); + err =iscsi_if_send_reply (portid, nlh->nlmsg_type, + ev,sizeof (*ev)); }while (err <0 && err != -ECONNREFUSED && err != -ESRCH );skb_pull (skb, rlen); }
Signature · 1 line
2.14.3
Quoted 10 lines · Chris Leech
Instead of always multicasting responses, send a unicast netlink message directed at the correct pid. This will be needed if we ever want to support multiple userspace processes interacting with the kernel over iSCSI netlink simultaneously. Limitations can currently be seen if you attempt to run multiple iscsistart commands in parallel.
We've fixed up the userspace issues in iscsistart that prevented multiple instances from running, so now attempts to speed up booting by bringing up multiple iscsi sessions at once in the initramfs are just running into misrouted responses that this fixes.
As you may know, I disagree with running multiple iscsistart-s at the same time, since that's what iscsid is for.
Never the less, I believe we _should_ be able to have multiple processes talking to the kernel target code, so I agree with these changes.
Quoted 8 lines
Signed-off-by Chris Leech <[email protected]>--- drivers/scsi/scsi_transport_iscsi.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-)... (diffs removed to save electrons)
Signature · 2 lines
Lee Duncan SUSE Labs
A message that is not in the archive (sent off-list or not yet received): 20180409221528.67880-1-cleech-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Martin K. Petersen
AppliedChris,
Quoted 10 lines
Instead of always multicasting responses, send a unicast netlink message directed at the correct pid. This will be needed if we ever want to support multiple userspace processes interacting with the kernel over iSCSI netlink simultaneously. Limitations can currently be seen if you attempt to run multiple iscsistart commands in parallel.
We've fixed up the userspace issues in iscsistart that prevented multiple instances from running, so now attempts to speed up booting by bringing up multiple iscsi sessions at once in the initramfs are just running into misrouted responses that this fixes.
Applied to 4.17/scsi-fixes. Thanks!
Signature · 8 lines
Martin K. Petersen Oracle Linux Engineering -- 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected] To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFF+G/[email protected] Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.