* REQ GID enforcement in the CM
@ 2011-10-27 14:14 Or Gerlitz
[not found] ` <4EA9672F.2010601-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Or Gerlitz @ 2011-10-27 14:14 UTC (permalink / raw)
To: Hefty, Sean, linux-rdma-u79uwXL29TY76Z2rM5mHXA; +Cc: Moni Shoua, Oren Duer
Hi Sean,
Looking on that case, I noted that the CM code (SB) checks that the GID
in the incoming
REQ is present in at least of one the ports of the relevant device, but
not specifically on
the port this request arrived to, is that following IBTA? I thought it
could be problematic
e.g in the case of RC QP being set by this establishment, later the RC
packets would be dropped
by the device if they have GRH and the GID isn't on that port table,
isn't that?
Or.
> ret = cm_init_av_by_path(&work->path[0], &cm_id_priv->av);
> if (ret) {
> ib_get_cached_gid(work->port->cm_dev->ib_device,
> work->port->port_num, 0,
> &work->path[0].sgid);
> ib_send_cm_rej(cm_id, IB_CM_REJ_INVALID_GID,
> &work->path[0].sgid, sizeof work->path[0].sgid,
> NULL, 0);
> goto rejected;
> }
> read_lock_irqsave(&cm.device_lock, flags);
> list_for_each_entry(cm_dev, &cm.device_list, list) {
> if (!ib_find_cached_gid(cm_dev->ib_device, &path->sgid,
> &p, NULL)) {
> port = cm_dev->port[p-1];
> break;
> }
> }
> read_unlock_irqrestore(&cm.device_lock, flags);
>
> if (!port)
> return -EINVAL;
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: REQ GID enforcement in the CM
[not found] ` <4EA9672F.2010601-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
@ 2011-10-27 16:55 ` Jason Gunthorpe
[not found] ` <20111027165522.GA16878-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Jason Gunthorpe @ 2011-10-27 16:55 UTC (permalink / raw)
To: Or Gerlitz
Cc: Hefty, Sean, linux-rdma-u79uwXL29TY76Z2rM5mHXA, Moni Shoua, Oren Duer
On Thu, Oct 27, 2011 at 04:14:07PM +0200, Or Gerlitz wrote:
> Looking on that case, I noted that the CM code (SB) checks that the
> GID in the incoming REQ is present in at least of one the ports of
> the relevant device, but not specifically on the port this request
> arrived to, is that following IBTA? I thought it could be
> problematic e.g in the case of RC QP being set by this
> establishment, later the RC packets would be dropped by the device
> if they have GRH and the GID isn't on that port table, isn't that?
You can use the CM to establish a connection on another port, eg send
CM GMPs to port 1, specify the primary data path is port 2 and specify
the alternate data path is port 1.
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: REQ GID enforcement in the CM
[not found] ` <20111027165522.GA16878-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
@ 2011-10-30 10:14 ` Or Gerlitz
[not found] ` <4EAD239A.2050702-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
0 siblings, 1 reply; 4+ messages in thread
From: Or Gerlitz @ 2011-10-30 10:14 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Hefty, Sean, linux-rdma-u79uwXL29TY76Z2rM5mHXA
On 10/27/2011 6:55 PM, Jason Gunthorpe wrote:
> You can use the CM to establish a connection on another port, eg send
> CM GMPs to port 1, specify the primary data path is port 2 and specify
> the alternate data path is port 1. Jason
makes sense, still, maybe the code here could/should be made more strict
here for
the case of a REQ sent with primary path only, agree?
Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: REQ GID enforcement in the CM
[not found] ` <4EAD239A.2050702-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
@ 2011-10-31 18:19 ` Jason Gunthorpe
0 siblings, 0 replies; 4+ messages in thread
From: Jason Gunthorpe @ 2011-10-31 18:19 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Hefty, Sean, linux-rdma-u79uwXL29TY76Z2rM5mHXA
On Sun, Oct 30, 2011 at 12:14:50PM +0200, Or Gerlitz wrote:
> On 10/27/2011 6:55 PM, Jason Gunthorpe wrote:
> >You can use the CM to establish a connection on another port, eg
> >send CM GMPs to port 1, specify the primary data path is port 2
> >and specify the alternate data path is port 1. Jason
>
> makes sense, still, maybe the code here could/should be made more
> strict here for the case of a REQ sent with primary path only,
> agree?
I'm not quite sure what you are proposing?
IBA places no requirements on the how the GMP path for CM messages is
related to the data path.
The only validation you can do is to ensure that end port described by
the GID also has the LID as part of its LID/LMC range, which I thought
I saw happening?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-10-31 18:19 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-27 14:14 REQ GID enforcement in the CM Or Gerlitz
[not found] ` <4EA9672F.2010601-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2011-10-27 16:55 ` Jason Gunthorpe
[not found] ` <20111027165522.GA16878-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2011-10-30 10:14 ` Or Gerlitz
[not found] ` <4EAD239A.2050702-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
2011-10-31 18:19 ` Jason Gunthorpe
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.