From: Cheng Xu <chengyou@linux.alibaba.com>
To: Bernard Metzler <BMT@zurich.ibm.com>,
"jgg@ziepe.ca" <jgg@ziepe.ca>,
"leon@kernel.org" <leon@kernel.org>
Cc: "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH for-next] RDMA/siw: Fix duplicated reported IW_CM_EVENT_CONNECT_REPLY event
Date: Thu, 14 Jul 2022 21:20:03 +0800 [thread overview]
Message-ID: <23ee6969-c32d-911a-2430-d9e3f6c52a61@linux.alibaba.com> (raw)
In-Reply-To: <BYAPR15MB2631D5F21C907B6145DABE4C99889@BYAPR15MB2631.namprd15.prod.outlook.com>
On 7/14/22 8:59 PM, Bernard Metzler wrote:
>> -----Original Message-----
>> From: Cheng Xu <chengyou@linux.alibaba.com>
>> Sent: Thursday, 14 July 2022 03:31
>> To: jgg@ziepe.ca; leon@kernel.org; Bernard Metzler <BMT@zurich.ibm.com>
>> Cc: linux-rdma@vger.kernel.org; chengyou@linux.alibaba.com
>> Subject: [EXTERNAL] [PATCH for-next] RDMA/siw: Fix duplicated reported
>> IW_CM_EVENT_CONNECT_REPLY event
>>
>> If siw_recv_mpa_rr returns -EAGAIN, it means that the MPA reply hasn't
>> been received completely, and should not report IW_CM_EVENT_CONNECT_REPLY
>> in this case. This may trigger a call trace in iw_cm. A simple way to
>> trigger this:
>
> Great, thanks! I obviously did never hit an incomplete
> MPA hdr. Please make another change to fix it correctly,
> as suggested below.
>
>
> case of an incomplete
>> server: ib_send_lat
>> client: ib_send_lat -R <server_ip>
>>
>> The call trace looks like this:
>>
>> kernel BUG at drivers/infiniband/core/iwcm.c:894!
>> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
>> <...>
>> Workqueue: iw_cm_wq cm_work_handler [iw_cm]
>> Call Trace:
>> <TASK>
>> cm_work_handler+0x1dd/0x370 [iw_cm]
>> process_one_work+0x1e2/0x3b0
>> worker_thread+0x49/0x2e0
>> ? rescuer_thread+0x370/0x370
>> kthread+0xe5/0x110
>> ? kthread_complete_and_exit+0x20/0x20
>> ret_from_fork+0x1f/0x30
>> </TASK>
>>
>> Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com>
>> ---
>> drivers/infiniband/sw/siw/siw_cm.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/infiniband/sw/siw/siw_cm.c
>> b/drivers/infiniband/sw/siw/siw_cm.c
>> index 17f34d584cd9..f88d2971c2c6 100644
>> --- a/drivers/infiniband/sw/siw/siw_cm.c
>> +++ b/drivers/infiniband/sw/siw/siw_cm.c
>> @@ -725,11 +725,11 @@ static int siw_proc_mpareply(struct siw_cep *cep)
>> enum mpa_v2_ctrl mpa_p2p_mode = MPA_V2_RDMA_NO_RTR;
>>
>> rv = siw_recv_mpa_rr(cep);
>> - if (rv != -EAGAIN)
>> - siw_cancel_mpatimer(cep);
>> if (rv)
>> goto out_err;
>>
>> + siw_cancel_mpatimer(cep);
>> +
>
> Cancel the MPA timer only if we have a
> real error. -EAGAIN translates to just
> further waiting. So best to add the timer
> cancellation to the error bailout section.
>
>> rep = &cep->mpa.hdr;
>>
>> if (__mpa_rr_revision(rep->params.bits) > MPA_REVISION_2) {
>> @@ -895,7 +895,8 @@ static int siw_proc_mpareply(struct siw_cep *cep)
>> }
>>
>> out_err:
>> - siw_cm_upcall(cep, IW_CM_EVENT_CONNECT_REPLY, -EINVAL);
>> + if (rv != -EAGAIN)
> {
> cancel MPA timer here.
Indeed we do not need it here, because when siw_proc_mpareply returns error
but not -EAGAIN, the release_cep will be set in the caller (siw_cm_work_handler),
and siw_cancel_mpatimer will be called in the error handle flow.
I think this is better, because the error handle is more unified.
How do you think?
Thanks,
Cheng Xu
> siw_cancel_mpatimer(cep);
>> + siw_cm_upcall(cep, IW_CM_EVENT_CONNECT_REPLY, -EINVAL);
> }
>>
>> return rv;
>> }
>> --
>> 2.37.0
>
next prev parent reply other threads:[~2022-07-14 13:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-14 12:59 [PATCH for-next] RDMA/siw: Fix duplicated reported IW_CM_EVENT_CONNECT_REPLY event Bernard Metzler
2022-07-14 13:20 ` Cheng Xu [this message]
2022-07-14 13:58 ` Bernard Metzler
-- strict thread matches above, loose matches on Subject: below --
2022-07-14 1:30 Cheng Xu
2022-07-18 11:21 ` Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23ee6969-c32d-911a-2430-d9e3f6c52a61@linux.alibaba.com \
--to=chengyou@linux.alibaba.com \
--cc=BMT@zurich.ibm.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox