All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Edward Srouji <edwards@nvidia.com>
To: "Pearson, Robert B" <rpearsonhpe@gmail.com>,
	Leon Romanovsky <leon@kernel.org>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
	RDMA mailing list <linux-rdma@vger.kernel.org>
Subject: Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation
Date: Tue, 8 Jun 2021 19:10:06 +0300	[thread overview]
Message-ID: <48ca9473-0fbf-d62f-72cd-fbb3de885b46@nvidia.com> (raw)
In-Reply-To: <bee1cfd7-09f1-5420-b09f-b6eb9de897e9@gmail.com>


On 6/8/2021 6:54 PM, Pearson, Robert B wrote:
> External email: Use caution opening links or attachments
>
>
> On 6/8/2021 6:53 AM, Edward Srouji wrote:
>>
>> On 6/8/2021 9:47 AM, Leon Romanovsky wrote:
>>> On Mon, Jun 07, 2021 at 11:54:29PM -0500, Pearson, Robert B wrote:
>>>> On 6/7/2021 11:41 PM, Leon Romanovsky wrote:
>>>>> On Mon, Jun 07, 2021 at 04:50:20PM -0500, Pearson, Robert B wrote:
>>>>>> sorry/this time without the HTML.
>>>>>>
>>>>>> ====================================================================== 
>>>>>>
>>>>>>
>>>>>> ERROR: test_qp_ex_rc_bind_mw (tests.test_qpex.QpExTestCase)
>>>>>> Verify bind memory window operation using the new post_send API.
>>>>>> ---------------------------------------------------------------------- 
>>>>>>
>>>>>>
>>>>>> Traceback (most recent call last):
>>>>>>     File "/home/rpearson/src/rdma-core/tests/test_qpex.py", line
>>>>>> 292, in
>>>>>> test_qp_ex_rc_bind_mw
>>>>>>       u.poll_cq(server.cq)
>>>>>>     File "/home/rpearson/src/rdma-core/tests/utils.py", line 538,
>>>>>> in poll_cq
>>>>>>       raise PyverbsRDMAError('Completion status is {s}'.
>>>>>> pyverbs.pyverbs_error.PyverbsRDMAError: Completion status is
>>>>>> Memory window
>>>>>> bind error. Errno: 6, No such device or address
>>>>>>
>>>>>> This test attempts to bind a type 2 MW to an MR that does not have
>>>>>> bind mw
>>>>>> access set and expects the test to succeed.
>>
>> You're right, looks like a test bug. I'll send a fix upstream.
>>
>> Can you please confirm that this solves your issue:
> Well I get further. I am hitting a seg fault in python at
>
>         client.qp.wr_rdma_write(new_key, server.mr.buf)
>
> in test_qp_ex_rc_bind_mw.
>
> I'm trying to track it down. I'm not very familiar with python and don't
> know how to run the test under gdb.
>
I don't see the issue on mlx devices / rxe.

You can use gdb for python using: "gdb python"

Then : "run <program>" e.g.: "run tests/run_tests.py -k 
test_qp_ex_rc_bind_mw" (if you ran the command from the rdma-core root dir).

You can set breakpoints for C functions as you regularly do. If you want 
to add a breakpoint to the python test, I suggest you do "import pdb; 
pdb.set_trace()" at the line you want to set the bp at.

Good luck.

> Thanks for the fix.
>
> Bob
>
>>
>> diff --git a/tests/test_qpex.py b/tests/test_qpex.py
>> index 4b58260f..c2d67ee8 100644
>> --- a/tests/test_qpex.py
>> +++ b/tests/test_qpex.py
>> @@ -149,7 +149,7 @@ class QpExRCBindMw(RCResources):
>>          create_qp_ex(self, e.IBV_QPT_RC, e.IBV_QP_EX_WITH_BIND_MW)
>>
>>      def create_mr(self):
>> -        self.mr = u.create_custom_mr(self, e.IBV_ACCESS_REMOTE_WRITE)
>> +        self.mr = u.create_custom_mr(self, e.IBV_ACCESS_REMOTE_WRITE
>> | e.IBV_ACCESS_MW_BIND)
>>
>>>>> Does the test break after your MW series? Or will it break not-merged
>>>>> code yet?
>>>>>
>>>>> Generally speaking, we expect that developers run rdma-core tests and
>>>>> fixed/extend them prior to the submission.
>>>>>
>>>>> Thanks
>>>>>
>>>>>> Bob Pearson
>>>> Nope. I don't have real RNICs at home to test. But (see my note to
>>>> Zhu) the
>>>> non extended APIs do set the access flags correctly and the extended
>>>> test
>>>> case does not. The wr_bind_mw() function can't fix this for the test
>>>> case.
>>>> It has to set the access flags when it creates the MR and it didn't.
>>>> It is
>>>> possible that mlx5 doesn't check the bind access flag but that seems
>>>> unlikely.
>>> mlx5 devices support MW 1 & 2 and kernel checks that only these types
>>> can be accepted from the user space. This is why mlx5 doesn't need to
>>> check access flags again.
>>>
>>>     903 static int ib_uverbs_alloc_mw(struct uverbs_attr_bundle *attrs)
>>>     904 {
>>>
>>> ....
>>>
>>>     927         if (cmd.mw_type != IB_MW_TYPE_1 && cmd.mw_type !=
>>> IB_MW_TYPE_2) {
>>>     928                 ret = -EINVAL;
>>>     929                 goto err_put;
>>>     930         }
>>>
>>>
>>> Thanks
>>
>> I see that mlx5 checks the access flags in userspace only if MW_DEBUG
>> is turned on (in set_bind_wr()).
>>
>> I guess that's for the sake of performance, as it's part of the data
>> path.
>>
>>>> Bob
>>>>

  reply	other threads:[~2021-06-08 16:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-07 21:50 [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation Pearson, Robert B
2021-06-08  4:41 ` Leon Romanovsky
2021-06-08  4:54   ` Pearson, Robert B
2021-06-08  6:47     ` Leon Romanovsky
2021-06-08 11:53       ` Edward Srouji
2021-06-08 15:54         ` Pearson, Robert B
2021-06-08 16:10           ` Edward Srouji [this message]
2021-06-08 16:12           ` Pearson, Robert B
2021-06-08 16:22             ` Pearson, Robert B
2021-06-08 17:14               ` Edward Srouji
2021-06-08 17:36                 ` Pearson, Robert B
2021-06-08 16:46       ` Pearson, Robert B

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=48ca9473-0fbf-d62f-72cd-fbb3de885b46@nvidia.com \
    --to=edwards@nvidia.com \
    --cc=jgg@nvidia.com \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=rpearsonhpe@gmail.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.