* [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation
@ 2021-06-07 21:50 Pearson, Robert B
2021-06-08 4:41 ` Leon Romanovsky
0 siblings, 1 reply; 12+ messages in thread
From: Pearson, Robert B @ 2021-06-07 21:50 UTC (permalink / raw)
To: Jason Gunthorpe, RDMA mailing list
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.
Bob Pearson
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation 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 0 siblings, 1 reply; 12+ messages in thread From: Leon Romanovsky @ 2021-06-08 4:41 UTC (permalink / raw) To: Pearson, Robert B; +Cc: Jason Gunthorpe, RDMA mailing list 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. 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation 2021-06-08 4:41 ` Leon Romanovsky @ 2021-06-08 4:54 ` Pearson, Robert B 2021-06-08 6:47 ` Leon Romanovsky 0 siblings, 1 reply; 12+ messages in thread From: Pearson, Robert B @ 2021-06-08 4:54 UTC (permalink / raw) To: Leon Romanovsky; +Cc: Jason Gunthorpe, RDMA mailing list 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. > 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. Bob ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation 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 16:46 ` Pearson, Robert B 0 siblings, 2 replies; 12+ messages in thread From: Leon Romanovsky @ 2021-06-08 6:47 UTC (permalink / raw) To: Pearson, Robert B; +Cc: Jason Gunthorpe, RDMA mailing list 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. > > 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 > > Bob > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation 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:46 ` Pearson, Robert B 1 sibling, 1 reply; 12+ messages in thread From: Edward Srouji @ 2021-06-08 11:53 UTC (permalink / raw) To: Leon Romanovsky, Pearson, Robert B; +Cc: Jason Gunthorpe, RDMA mailing list 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: 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 >> ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation 2021-06-08 11:53 ` Edward Srouji @ 2021-06-08 15:54 ` Pearson, Robert B 2021-06-08 16:10 ` Edward Srouji 2021-06-08 16:12 ` Pearson, Robert B 0 siblings, 2 replies; 12+ messages in thread From: Pearson, Robert B @ 2021-06-08 15:54 UTC (permalink / raw) To: Edward Srouji, Leon Romanovsky; +Cc: Jason Gunthorpe, RDMA mailing list 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. 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 >>> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation 2021-06-08 15:54 ` Pearson, Robert B @ 2021-06-08 16:10 ` Edward Srouji 2021-06-08 16:12 ` Pearson, Robert B 1 sibling, 0 replies; 12+ messages in thread From: Edward Srouji @ 2021-06-08 16:10 UTC (permalink / raw) To: Pearson, Robert B, Leon Romanovsky; +Cc: Jason Gunthorpe, RDMA mailing list 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 >>>> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation 2021-06-08 15:54 ` Pearson, Robert B 2021-06-08 16:10 ` Edward Srouji @ 2021-06-08 16:12 ` Pearson, Robert B 2021-06-08 16:22 ` Pearson, Robert B 1 sibling, 1 reply; 12+ messages in thread From: Pearson, Robert B @ 2021-06-08 16:12 UTC (permalink / raw) To: Edward Srouji, Leon Romanovsky; +Cc: Jason Gunthorpe, RDMA mailing list On 6/8/2021 10:54 AM, Pearson, Robert B wrote: > > 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. > > Thanks for the fix. > > Bob OK got it. In the setup for the test you write class QpExRCBindMw(RCResources): def create_qps(self): 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 | e.IBV_ACCESS_MW_BIND) which asks for qp_ex->wr_bind_mw() to be set but later in the test you write client.qp.wr_rdma_write(new_key, server.mr.buf) which calls qp_ex->wr_rdma_write() which is not set causing the seg fault. I think you should have written create_qp_ex(self, e.IBV_QPT_RC, e.IBV_QP_EX_WITH_BIND_MW | e.IBV_QP_EX_WITH_RDMA_WRITE) since you need both extended QP operations. 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 >>>> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation 2021-06-08 16:12 ` Pearson, Robert B @ 2021-06-08 16:22 ` Pearson, Robert B 2021-06-08 17:14 ` Edward Srouji 0 siblings, 1 reply; 12+ messages in thread From: Pearson, Robert B @ 2021-06-08 16:22 UTC (permalink / raw) To: Edward Srouji, Leon Romanovsky; +Cc: Jason Gunthorpe, RDMA mailing list On 6/8/2021 11:12 AM, Pearson, Robert B wrote: > > On 6/8/2021 10:54 AM, Pearson, Robert B wrote: >> >> 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. >> >> Thanks for the fix. >> >> Bob > > OK got it. In the setup for the test you write > > class QpExRCBindMw(RCResources): > def create_qps(self): > 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 | > e.IBV_ACCESS_MW_BIND) > > which asks for qp_ex->wr_bind_mw() to be set but later in the test you > write > > client.qp.wr_rdma_write(new_key, server.mr.buf) > > which calls qp_ex->wr_rdma_write() which is not set causing the seg > fault. I think you should have written > > create_qp_ex(self, e.IBV_QPT_RC, e.IBV_QP_EX_WITH_BIND_MW > | e.IBV_QP_EX_WITH_RDMA_WRITE) > > since you need both extended QP operations. > > Bob With this patch the test is now running correctly diff --git a/tests/test_qpex.py b/tests/test_qpex.py index 20288d45..0316bfcb 100644 --- a/tests/test_qpex.py +++ b/tests/test_qpex.py @@ -146,10 +146,12 @@ class QpExRCAtomicFetchAdd(RCResources): class QpExRCBindMw(RCResources): def create_qps(self): - create_qp_ex(self, e.IBV_QPT_RC, e.IBV_QP_EX_WITH_BIND_MW) + create_qp_ex(self, e.IBV_QPT_RC, e.IBV_QP_EX_WITH_BIND_MW | + e.IBV_QP_EX_WITH_RDMA_WRITE) 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) class QpExTestCase(RDMATestCase): > >> >>> >>> 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 >>>>> ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation 2021-06-08 16:22 ` Pearson, Robert B @ 2021-06-08 17:14 ` Edward Srouji 2021-06-08 17:36 ` Pearson, Robert B 0 siblings, 1 reply; 12+ messages in thread From: Edward Srouji @ 2021-06-08 17:14 UTC (permalink / raw) To: Pearson, Robert B, Leon Romanovsky; +Cc: Jason Gunthorpe, RDMA mailing list On 6/8/2021 7:22 PM, Pearson, Robert B wrote: > External email: Use caution opening links or attachments > > > On 6/8/2021 11:12 AM, Pearson, Robert B wrote: >> >> On 6/8/2021 10:54 AM, Pearson, Robert B wrote: >>> >>> 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. >>> >>> Thanks for the fix. >>> >>> Bob >> >> OK got it. In the setup for the test you write >> >> class QpExRCBindMw(RCResources): >> def create_qps(self): >> 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 | >> e.IBV_ACCESS_MW_BIND) >> >> which asks for qp_ex->wr_bind_mw() to be set but later in the test you >> write >> >> client.qp.wr_rdma_write(new_key, server.mr.buf) >> >> which calls qp_ex->wr_rdma_write() which is not set causing the seg >> fault. I think you should have written >> >> create_qp_ex(self, e.IBV_QPT_RC, e.IBV_QP_EX_WITH_BIND_MW >> | e.IBV_QP_EX_WITH_RDMA_WRITE) >> >> since you need both extended QP operations. >> >> Bob > > With this patch the test is now running correctly > > diff --git a/tests/test_qpex.py b/tests/test_qpex.py > index 20288d45..0316bfcb 100644 > --- a/tests/test_qpex.py > +++ b/tests/test_qpex.py > @@ -146,10 +146,12 @@ class QpExRCAtomicFetchAdd(RCResources): > > class QpExRCBindMw(RCResources): > def create_qps(self): > - create_qp_ex(self, e.IBV_QPT_RC, e.IBV_QP_EX_WITH_BIND_MW) > + create_qp_ex(self, e.IBV_QPT_RC, e.IBV_QP_EX_WITH_BIND_MW | > + e.IBV_QP_EX_WITH_RDMA_WRITE) > > 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) > > I've sent a fix patch for upstream (you can see at github). > class QpExTestCase(RDMATestCase): > >> >>> >>>> >>>> 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 >>>>>> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation 2021-06-08 17:14 ` Edward Srouji @ 2021-06-08 17:36 ` Pearson, Robert B 0 siblings, 0 replies; 12+ messages in thread From: Pearson, Robert B @ 2021-06-08 17:36 UTC (permalink / raw) To: Edward Srouji, Leon Romanovsky; +Cc: Jason Gunthorpe, RDMA mailing list On 6/8/2021 12:14 PM, Edward Srouji wrote: > > On 6/8/2021 7:22 PM, Pearson, Robert B wrote: >> External email: Use caution opening links or attachments >> >> >> On 6/8/2021 11:12 AM, Pearson, Robert B wrote: >>> >>> On 6/8/2021 10:54 AM, Pearson, Robert B wrote: >>>> >>>> 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. >>>> >>>> Thanks for the fix. >>>> >>>> Bob >>> >>> OK got it. In the setup for the test you write >>> >>> class QpExRCBindMw(RCResources): >>> def create_qps(self): >>> 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 | >>> e.IBV_ACCESS_MW_BIND) >>> >>> which asks for qp_ex->wr_bind_mw() to be set but later in the test you >>> write >>> >>> client.qp.wr_rdma_write(new_key, server.mr.buf) >>> >>> which calls qp_ex->wr_rdma_write() which is not set causing the seg >>> fault. I think you should have written >>> >>> create_qp_ex(self, e.IBV_QPT_RC, e.IBV_QP_EX_WITH_BIND_MW >>> | e.IBV_QP_EX_WITH_RDMA_WRITE) >>> >>> since you need both extended QP operations. >>> >>> Bob >> >> With this patch the test is now running correctly >> >> diff --git a/tests/test_qpex.py b/tests/test_qpex.py >> index 20288d45..0316bfcb 100644 >> --- a/tests/test_qpex.py >> +++ b/tests/test_qpex.py >> @@ -146,10 +146,12 @@ class QpExRCAtomicFetchAdd(RCResources): >> >> class QpExRCBindMw(RCResources): >> def create_qps(self): >> - create_qp_ex(self, e.IBV_QPT_RC, e.IBV_QP_EX_WITH_BIND_MW) >> + create_qp_ex(self, e.IBV_QPT_RC, e.IBV_QP_EX_WITH_BIND_MW | >> + e.IBV_QP_EX_WITH_RDMA_WRITE) >> >> 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) >> >> > I've sent a fix patch for upstream (you can see at github). Thanks! >> class QpExTestCase(RDMATestCase): >> >>> >>>> >>>>> >>>>> 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 >>>>>>> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Bug Report] RDMA/core: test_qpex.py attempts invalid MW bind operation 2021-06-08 6:47 ` Leon Romanovsky 2021-06-08 11:53 ` Edward Srouji @ 2021-06-08 16:46 ` Pearson, Robert B 1 sibling, 0 replies; 12+ messages in thread From: Pearson, Robert B @ 2021-06-08 16:46 UTC (permalink / raw) To: Leon Romanovsky; +Cc: Jason Gunthorpe, RDMA mailing list On 6/8/2021 1: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. >>> 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 You check the type in alloc_mw but you only check the MR access flags if MW_DEBUG is set which is not by default. So you would fail a negative test which we sort of currently have. The second bug in the test which we found this morning is not correctly setting the op flags in the create_qp_ex call. According to the man page only the extended operations set in the op flags are 'implemented' for that QP. Apparently mlx5 goes ahead and populates them. Makes more sense to me since the API as described is kind of overwrought and dumb. Bob ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-06-08 17:36 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.