From: liweihang <liweihang@huawei.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "dledford@redhat.com" <dledford@redhat.com>,
"leon@kernel.org" <leon@kernel.org>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
Linuxarm <linuxarm@huawei.com>
Subject: Re: [PATCH v2 for-next 05/11] RDMA/hns: WARN_ON if get a reserved sl from users
Date: Thu, 10 Dec 2020 13:55:11 +0000 [thread overview]
Message-ID: <54849771e0724e8eb05757996dca9716@huawei.com> (raw)
In-Reply-To: 20201210134516.GY5487@ziepe.ca
On 2020/12/10 21:45, Jason Gunthorpe wrote:
> On Thu, Dec 10, 2020 at 04:00:16AM +0000, liweihang wrote:
>> On 2020/12/10 5:09, Jason Gunthorpe wrote:
>>> On Fri, Dec 04, 2020 at 06:40:30PM +0800, Weihang Li wrote:
>>>> According to the RoCE v1 specification, the sl (service level) 0-7 are
>>>> mapped directly to priorities 0-7 respectively, sl 8-15 are reserved. The
>>>> driver should verify whether the value of sl is larger than 7, if so, an
>>>> exception should be returned.
>>>>
>>>> Fixes: 172505cfa3a8 ("RDMA/hns: Add check for the validity of sl configuration")
>>>> Fixes: d6a3627e311c ("RDMA/hns: Optimize wqe buffer set flow for post send")
>>>> Signed-off-by: Weihang Li <liweihang@huawei.com>
>>>> drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 10 +++++-----
>>>> 1 file changed, 5 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>>>> index 7a0c1ab..15e1313 100644
>>>> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>>>> @@ -433,6 +433,10 @@ static int fill_ud_av(struct hns_roce_v2_ud_send_wqe *ud_sq_wqe,
>>>> V2_UD_SEND_WQE_BYTE_36_TCLASS_S, ah->av.tclass);
>>>> roce_set_field(ud_sq_wqe->byte_40, V2_UD_SEND_WQE_BYTE_40_FLOW_LABEL_M,
>>>> V2_UD_SEND_WQE_BYTE_40_FLOW_LABEL_S, ah->av.flowlabel);
>>>> +
>>>> + if (WARN_ON(ah->av.sl > MAX_SERVICE_LEVEL))
>>>> + return -EINVAL;
>>>> +
>>>> roce_set_field(ud_sq_wqe->byte_40, V2_UD_SEND_WQE_BYTE_40_SL_M,
>>>> V2_UD_SEND_WQE_BYTE_40_SL_S, ah->av.sl);
>>>>
>>>> @@ -4609,12 +4613,8 @@ static int hns_roce_v2_set_path(struct ib_qp *ibqp,
>>>> memset(qpc_mask->dgid, 0, sizeof(grh->dgid.raw));
>>>>
>>>> hr_qp->sl = rdma_ah_get_sl(&attr->ah_attr);
>>>> - if (unlikely(hr_qp->sl > MAX_SERVICE_LEVEL)) {
>>>> - ibdev_err(ibdev,
>>>> - "failed to fill QPC, sl (%d) shouldn't be larger than %d.\n",
>>>> - hr_qp->sl, MAX_SERVICE_LEVEL);
>>>> + if (WARN_ON(hr_qp->sl > MAX_SERVICE_LEVEL))
>>>> return -EINVAL;
>>>> - }
>>>>
>>>> roce_set_field(context->byte_28_at_fl, V2_QPC_BYTE_28_SL_M,
>>>> V2_QPC_BYTE_28_SL_S, hr_qp->sl);
>>>
>>> Can any of these warn_on's be triggered by user space? That would not
>>> be OK
>>>
>>> Jason
>>>
>>
>> Hi Jason,
>>
>> Thanks for your comments, I understand that error that can be triggered by
>> userspace shouldn't use WARN_ON(). So I shouldn't use WARN_ON() in
>> hns_roce_v2_set_path().
>>
>> As for the error in process of post_send, you suggested me to warn_on if
>> a kernel user try to pass in an illegal opcode. So I guess I should use
>> WARN_ON() too in sl's check when filling a UD WQE. Am I right?
>
> Userspace should not be able to trigger warn_on
>
> Bad kernel ULPs are OK to trigger warn_on
>
> Jason
>
I see, Thank you.
Weihang
next prev parent reply other threads:[~2020-12-10 13:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-04 10:40 [PATCH v2 for-next 00/11] RDMA/hns: Updates for 5.11 Weihang Li
2020-12-04 10:40 ` [PATCH v2 for-next 01/11] RDMA/hns: Limit the length of data copied between kernel and userspace Weihang Li
2020-12-04 10:40 ` [PATCH v2 for-next 02/11] RDMA/hns: Normalization the judgment of some features Weihang Li
2020-12-04 10:40 ` [PATCH v2 for-next 03/11] RDMA/hns: Do shift on traffic class when using RoCEv2 Weihang Li
2020-12-04 10:40 ` [PATCH v2 for-next 04/11] RDMA/hns: Avoid filling sl in high 3 bits of vlan_id Weihang Li
2020-12-04 10:40 ` [PATCH v2 for-next 05/11] RDMA/hns: WARN_ON if get a reserved sl from users Weihang Li
2020-12-09 21:09 ` Jason Gunthorpe
2020-12-10 4:00 ` liweihang
2020-12-10 13:45 ` Jason Gunthorpe
2020-12-10 13:55 ` liweihang [this message]
2020-12-04 10:40 ` [PATCH v2 for-next 06/11] RDMA/hns: Remove unnecessary access right set during INIT2INIT Weihang Li
2020-12-04 10:40 ` [PATCH v2 for-next 07/11] RDMA/hns: Fix coding style issues Weihang Li
2020-12-04 10:40 ` [PATCH v2 for-next 08/11] RDMA/hns: Clear redundant variable initialization Weihang Li
2020-12-04 10:40 ` [PATCH v2 for-next 09/11] RDMA/hns: Fix incorrect symbol types Weihang Li
2020-12-04 10:40 ` [PATCH v2 for-next 10/11] RDMA/hns: Fix inaccurate prints Weihang Li
2020-12-04 10:40 ` [PATCH v2 for-next 11/11] RDMA/hns: Simplify AEQE process for different types of queue Weihang Li
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=54849771e0724e8eb05757996dca9716@huawei.com \
--to=liweihang@huawei.com \
--cc=dledford@redhat.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linuxarm@huawei.com \
/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 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.