Am Freitag, den 21.07.2006, 09:42 -0700 schrieb Sean Hefty:
> Arne Redlich wrote:
> > I only took a rather superficial look at the code. But since the invalid
> > GID REJ is treated with such care, I guess it's intentional and not a
> > bug?
>
> I would lean more towards it being a bug. The data
Arne Redlich wrote:
> I only took a rather superficial look at the code. But since the invalid
> GID REJ is treated with such care, I guess it's intentional and not a
> bug?
I would lean more towards it being a bug. The data in the CM REQ is wrong.
(There's a difference between rejecting a reque
Am Donnerstag, den 20.07.2006, 18:44 +0300 schrieb Michael S. Tsirkin:
> Quoting r. Arne Redlich <[EMAIL PROTECTED]>:
> > Subject: Re: [openib-general] [PATCH 2/2] ib_cm: fix REJ due to invalid GID
> >
> > Am Mittwoch, den 19.07.2006, 20:05 +0300 schrieb Michael S. Tsi
Quoting r. Arne Redlich <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] [PATCH 2/2] ib_cm: fix REJ due to invalid GID
>
> Am Mittwoch, den 19.07.2006, 20:05 +0300 schrieb Michael S. Tsirkin:
> > Quoting r. Arne Redlich <[EMAIL PROTECTED]>:
> > > Subj
Am Mittwoch, den 19.07.2006, 20:05 +0300 schrieb Michael S. Tsirkin:
> Quoting r. Arne Redlich <[EMAIL PROTECTED]>:
> > Subject: Re: [openib-general] [PATCH 2/2] ib_cm: fix REJ due to invalid GID
> >
> > Am Dienstag, den 18.07.2006, 12:21 -0700 schrieb Sean Heft
Quoting r. Arne Redlich <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] [PATCH 2/2] ib_cm: fix REJ due to invalid GID
>
> Am Dienstag, den 18.07.2006, 12:21 -0700 schrieb Sean Hefty:
> > Arne Redlich wrote:
> > > Yep - the Gen1 SRP initiator does. It se
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH 2/2] ib_cm: fix REJ due to invalid GID
>
> Michael> By the way, AFAIK by design cache might be out of sync
> Michael> with actual hardware. Roland, could you confirm this
> Michael> pls?
>
> Yes, that's true. But ev
Am Dienstag, den 18.07.2006, 12:21 -0700 schrieb Sean Hefty:
> Arne Redlich wrote:
> > Yep - the Gen1 SRP initiator does. It sends a REQ with an invalid DGID.
> > If rejected with the correct code (INVALID GID), it will retry after
> > looking up the GID.
>
> Didn't it have a DGID from a path reco
Am Dienstag, den 18.07.2006, 10:09 -0700 schrieb Sean Hefty:
> Arne Redlich wrote:
> > @@ -1354,6 +1354,7 @@ static int cm_req_handler(struct cm_work
> > id.local_id);
> > if (IS_ERR(cm_id_priv->timewait_info)) {
> > ret = PTR_
Michael> By the way, AFAIK by design cache might be out of sync
Michael> with actual hardware. Roland, could you confirm this
Michael> pls?
Yes, that's true. But even without cache, since the update of GID and
P_Key tables is asynchronous, there's nothing that prevents the result
of
Arne Redlich wrote:
> Yep - the Gen1 SRP initiator does. It sends a REQ with an invalid DGID.
> If rejected with the correct code (INVALID GID), it will retry after
> looking up the GID.
Didn't it have a DGID from a path record that it had to get before sending the
REQ?
>>> cm_format_paths_f
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: RE: [PATCH 2/2] ib_cm: fix REJ due to invalid GID
>
> >By the way, AFAIK by design cache might be out of sync with actual hardware.
> >Roland, could you confirm this pls?
> >
> >So if we look things up in cache and they are not there there mus
>By the way, AFAIK by design cache might be out of sync with actual hardware.
>Roland, could you confirm this pls?
>
>So if we look things up in cache and they are not there there must be
>a retry strategy which is missing if we reject the connection.
>A quick solution would be to force cache upda
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] [PATCH 2/2] ib_cm: fix REJ due to invalid GID
>
> Michael S. Tsirkin wrote:
> >>ret = cm_init_av_by_path(&work->path[1], &cm_id_priv->alt_av);
> >&
Michael S. Tsirkin wrote:
>> ret = cm_init_av_by_path(&work->path[1], &cm_id_priv->alt_av);
>>- if (ret)
>>+ if (ret) {
>>+ cm_issue_rej(work->port, work->mad_recv_wc,
>>+ IB_CM_INVALID_ALT_GID, CM_MSG_RESPONS
Arne Redlich wrote:
> @@ -1354,6 +1354,7 @@ static int cm_req_handler(struct cm_work
> id.local_id);
> if (IS_ERR(cm_id_priv->timewait_info)) {
> ret = PTR_ERR(cm_id_priv->timewait_info);
> + reject = 1;
>
On Tue, 2006-07-18 at 11:19, Michael S. Tsirkin wrote:
[snip...]
> > > I also
> > > wander what should the status be if there are multiple errors in a REQ.
> >
> > The first one discovered, no?
>
> Or maybe the most severe one? The spec seems fuzzy in this respect ...
There is no defined preced
Quoting r. Arne Redlich <[EMAIL PROTECTED]>:
> > > Reject a REQ containing invalid GID(s) with appropriate reason codes
> > > instead of IB_CM_CONSUMER_REJ.
> > >
> > > Signed-off-by: Arne Redlich <[EMAIL PROTECTED]>
> >
> > Are there actual applications that can use the exact reject status?
>
Am Dienstag, den 18.07.2006, 17:43 +0300 schrieb Michael S. Tsirkin:
> Quoting r. Arne Redlich <[EMAIL PROTECTED]>:
> > Reject a REQ containing invalid GID(s) with appropriate reason codes
> > instead of IB_CM_CONSUMER_REJ.
> >
> > Signed-off-by: Arne Redlich <[EMAIL PROTECTED]>
>
> Are there act
Quoting r. Arne Redlich <[EMAIL PROTECTED]>:
> Reject a REQ containing invalid GID(s) with appropriate reason codes
> instead of IB_CM_CONSUMER_REJ.
>
> Signed-off-by: Arne Redlich <[EMAIL PROTECTED]>
Are there actual applications that can use the exact reject status? I also
wander what should t
> +if (ret) {
> +cm_issue_rej(work->port, work->mad_recv_wc, IB_CM_INVALID_GID,
> + CM_MSG_RESPONSE_REQ, NULL, 0);
> +reject = 0;
> goto error3;
> +}
This seems rather awkward -- send a REJ and then set reject to 0?
Maybe
Reject a REQ containing invalid GID(s) with appropriate reason codes
instead of IB_CM_CONSUMER_REJ.
Signed-off-by: Arne Redlich <[EMAIL PROTECTED]>
Index: infiniband/core/cm.c
===
--- infiniband/core/cm.c(revision 8556)
+++ i
22 matches
Mail list logo
