All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.