linux-kernel - Re: [PATCH v2 2/2] RDMA/rxe: Generate error completion for error requester state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 11 May 2022 08:36:01 +0000
From:   "lizhijian@...itsu.com" <lizhijian@...itsu.com>
To:     Cheng Xu <chengyou@...ux.alibaba.com>,
        Zhu Yanjun <zyjzyj2000@...il.com>,
        Jason Gunthorpe <jgg@...pe.ca>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] RDMA/rxe: Generate error completion for error
 requester state



On 11/05/2022 11:44, Cheng Xu wrote:
>
>
> On 5/11/22 10:30 AM, Li Zhijian wrote:
>> SoftRoCE always returns success when user space is posting a new wqe where
>> it usually just enqueues a wqe.
>>
>> Once the requester state becomes QP_STATE_ERROR, we should generate error
>> completion for all subsequent wqe. So the user is able to poll the
>> completion event to check if the former wqe is handled correctly.
>>
>> Here we check QP_STATE_ERROR after req_next_wqe() so that the completion
>> can associate with its wqe.
>>
>> Signed-off-by: Li Zhijian <lizhijian@...itsu.com>
>> ---
>>   drivers/infiniband/sw/rxe/rxe_req.c | 10 +++++++++-
>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/infiniband/sw/rxe/rxe_req.c b/drivers/infiniband/sw/rxe/rxe_req.c
>> index 8bdd0b6b578f..ed6a486c4343 100644
>> --- a/drivers/infiniband/sw/rxe/rxe_req.c
>> +++ b/drivers/infiniband/sw/rxe/rxe_req.c
>> @@ -624,7 +624,7 @@ int rxe_requester(void *arg)
>>       rxe_get(qp);
>>     next_wqe:
>> -    if (unlikely(!qp->valid || qp->req.state == QP_STATE_ERROR))
>> +    if (unlikely(!qp->valid))
>>           goto exit;
>>         if (unlikely(qp->req.state == QP_STATE_RESET)) {
>> @@ -646,6 +646,14 @@ int rxe_requester(void *arg)
>>       if (unlikely(!wqe))
>>           goto exit;
>>   +    if (qp->req.state == QP_STATE_ERROR) {
>> +        /*
>> +         * Generate an error completion so that user space is able to
>> +         * poll this completion.
>> +         */
>> +        goto err;
>> +    }
>> +
>
> Should this still use unlikely(...) ? Because the original judgement has
> a unlikely surrounded.

Good catch. it sounds good :)


Thanks
Zhijian



>
> Cheng Xu
>
>>       if (wqe->mask & WR_LOCAL_OP_MASK) {
>>           ret = rxe_do_local_ops(qp, wqe);
>>           if (unlikely(ret))