* [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in get_new_pps
@ 2020-02-27 12:57 Leon Romanovsky
2020-02-27 14:07 ` Marciniszyn, Mike
2020-02-28 15:23 ` Jason Gunthorpe
0 siblings, 2 replies; 7+ messages in thread
From: Leon Romanovsky @ 2020-02-27 12:57 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe; +Cc: Maor Gottlieb, linux-rdma
From: Maor Gottlieb <maorg@mellanox.com>
When port is part of the modify mask, then we should take
it from the qp_attr and not from the old pps. Same for PKEY.
Cc: <stable@vger.kernel.org>
Fixes: 1dd017882e01 ("RDMA/core: Fix protection fault in get_pkey_idx_qp_list")
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/core/security.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/core/security.c b/drivers/infiniband/core/security.c
index b9a36ea244d4..2d5608315dc8 100644
--- a/drivers/infiniband/core/security.c
+++ b/drivers/infiniband/core/security.c
@@ -340,11 +340,15 @@ static struct ib_ports_pkeys *get_new_pps(const struct ib_qp *qp,
return NULL;
if (qp_attr_mask & IB_QP_PORT)
- new_pps->main.port_num =
- (qp_pps) ? qp_pps->main.port_num : qp_attr->port_num;
+ new_pps->main.port_num = qp_attr->port_num;
+ else if (qp_pps)
+ new_pps->main.port_num = qp_pps->main.port_num;
+
if (qp_attr_mask & IB_QP_PKEY_INDEX)
- new_pps->main.pkey_index = (qp_pps) ? qp_pps->main.pkey_index :
- qp_attr->pkey_index;
+ new_pps->main.pkey_index = qp_attr->pkey_index;
+ else if (qp_pps)
+ new_pps->main.pkey_index = qp_pps->main.pkey_index;
+
if ((qp_attr_mask & IB_QP_PKEY_INDEX) && (qp_attr_mask & IB_QP_PORT))
new_pps->main.state = IB_PORT_PKEY_VALID;
--
2.24.1
^ permalink raw reply related [flat|nested] 7+ messages in thread
* RE: [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in get_new_pps
2020-02-27 12:57 [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in get_new_pps Leon Romanovsky
@ 2020-02-27 14:07 ` Marciniszyn, Mike
2020-02-27 19:01 ` Leon Romanovsky
2020-02-28 15:23 ` Jason Gunthorpe
1 sibling, 1 reply; 7+ messages in thread
From: Marciniszyn, Mike @ 2020-02-27 14:07 UTC (permalink / raw)
To: Leon Romanovsky, Doug Ledford, Jason Gunthorpe; +Cc: Maor Gottlieb, linux-rdma
>
> From: Maor Gottlieb <maorg@mellanox.com>
>
> When port is part of the modify mask, then we should take
> it from the qp_attr and not from the old pps. Same for PKEY.
>
> Cc: <stable@vger.kernel.org>
> Fixes: 1dd017882e01 ("RDMA/core: Fix protection fault in
> get_pkey_idx_qp_list")
> Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> drivers/infiniband/core/security.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/infiniband/core/security.c
> b/drivers/infiniband/core/security.c
> index b9a36ea244d4..2d5608315dc8 100644
> --- a/drivers/infiniband/core/security.c
> +++ b/drivers/infiniband/core/security.c
> @@ -340,11 +340,15 @@ static struct ib_ports_pkeys *get_new_pps(const
> struct ib_qp *qp,
> return NULL;
>
> if (qp_attr_mask & IB_QP_PORT)
> - new_pps->main.port_num =
> - (qp_pps) ? qp_pps->main.port_num : qp_attr-
> >port_num;
> + new_pps->main.port_num = qp_attr->port_num;
> + else if (qp_pps)
> + new_pps->main.port_num = qp_pps->main.port_num;
> +
> if (qp_attr_mask & IB_QP_PKEY_INDEX)
> - new_pps->main.pkey_index = (qp_pps) ? qp_pps-
> >main.pkey_index :
> - qp_attr->pkey_index;
> + new_pps->main.pkey_index = qp_attr->pkey_index;
> + else if (qp_pps)
> + new_pps->main.pkey_index = qp_pps->main.pkey_index;
> +
> if ((qp_attr_mask & IB_QP_PKEY_INDEX) && (qp_attr_mask &
> IB_QP_PORT))
> new_pps->main.state = IB_PORT_PKEY_VALID;
>
I agree with this aspect of the patch and it does fix the panic, because the correct unit
is gotten from qp_pps.
My issue is that the new_pps->main.state will come back as 0, and the insert routine will drop any new pkey index update.
The sequence I'm concerned about is:
0x71 attr mask with both pkey index and port.
A ulp decides to change the pkey index and does an 0x51 modify without setting the unit.
I see new_pps->main.state being returned as 0 and port_pkey_list_insert() will early out.
I asked this exact question in https://marc.info/?l=linux-rdma&m=158278763015030&w=2.
I also asked about the logical or, and you answered that pointing to an additional patch.
You but didn't address the main.state being 0 and losing the pkey_index update in the 0x51 modify.
Mike
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in get_new_pps
2020-02-27 14:07 ` Marciniszyn, Mike
@ 2020-02-27 19:01 ` Leon Romanovsky
2020-02-27 22:49 ` Marciniszyn, Mike
0 siblings, 1 reply; 7+ messages in thread
From: Leon Romanovsky @ 2020-02-27 19:01 UTC (permalink / raw)
To: Marciniszyn, Mike
Cc: Doug Ledford, Jason Gunthorpe, Maor Gottlieb, linux-rdma
On Thu, Feb 27, 2020 at 02:07:10PM +0000, Marciniszyn, Mike wrote:
> >
> > From: Maor Gottlieb <maorg@mellanox.com>
> >
> > When port is part of the modify mask, then we should take
> > it from the qp_attr and not from the old pps. Same for PKEY.
> >
> > Cc: <stable@vger.kernel.org>
> > Fixes: 1dd017882e01 ("RDMA/core: Fix protection fault in
> > get_pkey_idx_qp_list")
> > Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > ---
> > drivers/infiniband/core/security.c | 12 ++++++++----
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/infiniband/core/security.c
> > b/drivers/infiniband/core/security.c
> > index b9a36ea244d4..2d5608315dc8 100644
> > --- a/drivers/infiniband/core/security.c
> > +++ b/drivers/infiniband/core/security.c
> > @@ -340,11 +340,15 @@ static struct ib_ports_pkeys *get_new_pps(const
> > struct ib_qp *qp,
> > return NULL;
> >
> > if (qp_attr_mask & IB_QP_PORT)
> > - new_pps->main.port_num =
> > - (qp_pps) ? qp_pps->main.port_num : qp_attr-
> > >port_num;
> > + new_pps->main.port_num = qp_attr->port_num;
> > + else if (qp_pps)
> > + new_pps->main.port_num = qp_pps->main.port_num;
> > +
> > if (qp_attr_mask & IB_QP_PKEY_INDEX)
> > - new_pps->main.pkey_index = (qp_pps) ? qp_pps-
> > >main.pkey_index :
> > - qp_attr->pkey_index;
> > + new_pps->main.pkey_index = qp_attr->pkey_index;
> > + else if (qp_pps)
> > + new_pps->main.pkey_index = qp_pps->main.pkey_index;
> > +
> > if ((qp_attr_mask & IB_QP_PKEY_INDEX) && (qp_attr_mask &
> > IB_QP_PORT))
> > new_pps->main.state = IB_PORT_PKEY_VALID;
> >
>
> I agree with this aspect of the patch and it does fix the panic, because the correct unit
> is gotten from qp_pps.
>
> My issue is that the new_pps->main.state will come back as 0, and the insert routine will drop any new pkey index update.
>
> The sequence I'm concerned about is:
>
> 0x71 attr mask with both pkey index and port.
>
> A ulp decides to change the pkey index and does an 0x51 modify without setting the unit.
>
> I see new_pps->main.state being returned as 0 and port_pkey_list_insert() will early out.
I see, maybe we can store the main.state in qps and restore it from there?
>
> I asked this exact question in https://marc.info/?l=linux-rdma&m=158278763015030&w=2.
>
> I also asked about the logical or, and you answered that pointing to an additional patch.
>
> You but didn't address the main.state being 0 and losing the pkey_index update in the 0x51 modify.
>
> Mike
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in get_new_pps
2020-02-27 19:01 ` Leon Romanovsky
@ 2020-02-27 22:49 ` Marciniszyn, Mike
2020-02-28 15:02 ` Jason Gunthorpe
0 siblings, 1 reply; 7+ messages in thread
From: Marciniszyn, Mike @ 2020-02-27 22:49 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: Doug Ledford, Jason Gunthorpe, Maor Gottlieb, linux-rdma
> On Thu, Feb 27, 2020 at 02:07:10PM +0000, Marciniszyn, Mike wrote:
> > >
> > > From: Maor Gottlieb <maorg@mellanox.com>
> > >
> > > When port is part of the modify mask, then we should take
> > > it from the qp_attr and not from the old pps. Same for PKEY.
> > >
> > > Cc: <stable@vger.kernel.org>
> > > Fixes: 1dd017882e01 ("RDMA/core: Fix protection fault in
> > > get_pkey_idx_qp_list")
> > > Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
> > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > > ---
> > > drivers/infiniband/core/security.c | 12 ++++++++----
> > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/infiniband/core/security.c
> > > b/drivers/infiniband/core/security.c
> > > index b9a36ea244d4..2d5608315dc8 100644
> > > --- a/drivers/infiniband/core/security.c
> > > +++ b/drivers/infiniband/core/security.c
> > > @@ -340,11 +340,15 @@ static struct ib_ports_pkeys
> *get_new_pps(const
> > > struct ib_qp *qp,
> > > return NULL;
> > >
> > > if (qp_attr_mask & IB_QP_PORT)
> > > - new_pps->main.port_num =
> > > - (qp_pps) ? qp_pps->main.port_num : qp_attr-
> > > >port_num;
> > > + new_pps->main.port_num = qp_attr->port_num;
> > > + else if (qp_pps)
> > > + new_pps->main.port_num = qp_pps->main.port_num;
> > > +
> > > if (qp_attr_mask & IB_QP_PKEY_INDEX)
> > > - new_pps->main.pkey_index = (qp_pps) ? qp_pps-
> > > >main.pkey_index :
> > > - qp_attr->pkey_index;
> > > + new_pps->main.pkey_index = qp_attr->pkey_index;
> > > + else if (qp_pps)
> > > + new_pps->main.pkey_index = qp_pps->main.pkey_index;
> > > +
> > > if ((qp_attr_mask & IB_QP_PKEY_INDEX) && (qp_attr_mask &
> > > IB_QP_PORT))
> > > new_pps->main.state = IB_PORT_PKEY_VALID;
> > >
> >
> > I agree with this aspect of the patch and it does fix the panic, because the
> correct unit
> > is gotten from qp_pps.
> >
> > My issue is that the new_pps->main.state will come back as 0, and the
> insert routine will drop any new pkey index update.
> >
> > The sequence I'm concerned about is:
> >
> > 0x71 attr mask with both pkey index and port.
> >
> > A ulp decides to change the pkey index and does an 0x51 modify without
> setting the unit.
> >
> > I see new_pps->main.state being returned as 0 and port_pkey_list_insert()
> will early out.
>
> I see, maybe we can store the main.state in qps and restore it from there?
>
I don't think we need to go that far.
I think all we need to do is
if ((qp_attr_mask & IB_QP_PKEY_INDEX) && (qp_attr_mask & IB_QP_PORT))
new_pps->main.state = IB_PORT_PKEY_VALID;
else if ((qp_attr_mask & (IB_QP_PKEY_INDEX | IB_QP_PORT)) && qp_pps) {
/*
* one of the attributes modified and already copied above.
*
* correct the state based on qp_pps state
*/
if (qp_pps->main.state != IB_PORT_PKEY_NOT_VALID)
new_pps->main.state = IB_PORT_PKEY_VALID;
}
I'm ok will a follow-up patch after Maor's patch to fix remaining issues.
Right now, all of our upstream testing (5.6 rc3+, stables) is dead because of 1dd017882e01.
Mike
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in get_new_pps
2020-02-27 22:49 ` Marciniszyn, Mike
@ 2020-02-28 15:02 ` Jason Gunthorpe
2020-02-28 15:12 ` Marciniszyn, Mike
0 siblings, 1 reply; 7+ messages in thread
From: Jason Gunthorpe @ 2020-02-28 15:02 UTC (permalink / raw)
To: Marciniszyn, Mike
Cc: Leon Romanovsky, Doug Ledford, Maor Gottlieb, linux-rdma
On Thu, Feb 27, 2020 at 10:49:45PM +0000, Marciniszyn, Mike wrote:
> > On Thu, Feb 27, 2020 at 02:07:10PM +0000, Marciniszyn, Mike wrote:
> > > >
> > > > From: Maor Gottlieb <maorg@mellanox.com>
> > > >
> > > > When port is part of the modify mask, then we should take
> > > > it from the qp_attr and not from the old pps. Same for PKEY.
> > > >
> > > > Cc: <stable@vger.kernel.org>
> > > > Fixes: 1dd017882e01 ("RDMA/core: Fix protection fault in
> > > > get_pkey_idx_qp_list")
> > > > Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
> > > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > > > drivers/infiniband/core/security.c | 12 ++++++++----
> > > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/infiniband/core/security.c
> > > > b/drivers/infiniband/core/security.c
> > > > index b9a36ea244d4..2d5608315dc8 100644
> > > > +++ b/drivers/infiniband/core/security.c
> > > > @@ -340,11 +340,15 @@ static struct ib_ports_pkeys
> > *get_new_pps(const
> > > > struct ib_qp *qp,
> > > > return NULL;
> > > >
> > > > if (qp_attr_mask & IB_QP_PORT)
> > > > - new_pps->main.port_num =
> > > > - (qp_pps) ? qp_pps->main.port_num : qp_attr-
> > > > >port_num;
> > > > + new_pps->main.port_num = qp_attr->port_num;
> > > > + else if (qp_pps)
> > > > + new_pps->main.port_num = qp_pps->main.port_num;
> > > > +
> > > > if (qp_attr_mask & IB_QP_PKEY_INDEX)
> > > > - new_pps->main.pkey_index = (qp_pps) ? qp_pps-
> > > > >main.pkey_index :
> > > > - qp_attr->pkey_index;
> > > > + new_pps->main.pkey_index = qp_attr->pkey_index;
> > > > + else if (qp_pps)
> > > > + new_pps->main.pkey_index = qp_pps->main.pkey_index;
> > > > +
> > > > if ((qp_attr_mask & IB_QP_PKEY_INDEX) && (qp_attr_mask &
> > > > IB_QP_PORT))
> > > > new_pps->main.state = IB_PORT_PKEY_VALID;
> > > >
> > >
> > > I agree with this aspect of the patch and it does fix the panic, because the
> > correct unit
> > > is gotten from qp_pps.
> > >
> > > My issue is that the new_pps->main.state will come back as 0, and the
> > insert routine will drop any new pkey index update.
> > >
> > > The sequence I'm concerned about is:
> > >
> > > 0x71 attr mask with both pkey index and port.
> > >
> > > A ulp decides to change the pkey index and does an 0x51 modify without
> > setting the unit.
> > >
> > > I see new_pps->main.state being returned as 0 and port_pkey_list_insert()
> > will early out.
> >
> > I see, maybe we can store the main.state in qps and restore it from there?
> >
>
> I don't think we need to go that far.
>
> I think all we need to do is
>
> if ((qp_attr_mask & IB_QP_PKEY_INDEX) && (qp_attr_mask & IB_QP_PORT))
> new_pps->main.state = IB_PORT_PKEY_VALID;
> else if ((qp_attr_mask & (IB_QP_PKEY_INDEX | IB_QP_PORT)) && qp_pps) {
> /*
> * one of the attributes modified and already copied above.
> *
> * correct the state based on qp_pps state
> */
> if (qp_pps->main.state != IB_PORT_PKEY_NOT_VALID)
> new_pps->main.state = IB_PORT_PKEY_VALID;
> }
>
> I'm ok will a follow-up patch after Maor's patch to fix remaining issues.
Are you then OK with the patch Maor posted? Please add a tag. I'm
waiting for you :)
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
* RE: [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in get_new_pps
2020-02-28 15:02 ` Jason Gunthorpe
@ 2020-02-28 15:12 ` Marciniszyn, Mike
0 siblings, 0 replies; 7+ messages in thread
From: Marciniszyn, Mike @ 2020-02-28 15:12 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: Leon Romanovsky, Doug Ledford, Maor Gottlieb, linux-rdma
> -----Original Message-----
> From: Jason Gunthorpe <jgg@mellanox.com>
> Sent: Friday, February 28, 2020 10:03 AM
> To: Marciniszyn, Mike <mike.marciniszyn@intel.com>
> Cc: Leon Romanovsky <leon@kernel.org>; Doug Ledford
> <dledford@redhat.com>; Maor Gottlieb <maorg@mellanox.com>; linux-
> rdma@vger.kernel.org
> Subject: Re: [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in
> get_new_pps
>
> On Thu, Feb 27, 2020 at 10:49:45PM +0000, Marciniszyn, Mike wrote:
> > > On Thu, Feb 27, 2020 at 02:07:10PM +0000, Marciniszyn, Mike wrote:
> > > > >
> > > > > From: Maor Gottlieb <maorg@mellanox.com>
> > > > >
> > > > > When port is part of the modify mask, then we should take
> > > > > it from the qp_attr and not from the old pps. Same for PKEY.
> > > > >
> > > > > Cc: <stable@vger.kernel.org>
> > > > > Fixes: 1dd017882e01 ("RDMA/core: Fix protection fault in
> > > > > get_pkey_idx_qp_list")
> > > > > Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
> > > > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > > > > drivers/infiniband/core/security.c | 12 ++++++++----
> > > > > 1 file changed, 8 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/infiniband/core/security.c
> > > > > b/drivers/infiniband/core/security.c
> > > > > index b9a36ea244d4..2d5608315dc8 100644
> > > > > +++ b/drivers/infiniband/core/security.c
> > > > > @@ -340,11 +340,15 @@ static struct ib_ports_pkeys
> > > *get_new_pps(const
> > > > > struct ib_qp *qp,
> > > > > return NULL;
> > > > >
> > > > > if (qp_attr_mask & IB_QP_PORT)
> > > > > - new_pps->main.port_num =
> > > > > - (qp_pps) ? qp_pps->main.port_num :
> qp_attr-
> > > > > >port_num;
> > > > > + new_pps->main.port_num = qp_attr->port_num;
> > > > > + else if (qp_pps)
> > > > > + new_pps->main.port_num = qp_pps-
> >main.port_num;
> > > > > +
> > > > > if (qp_attr_mask & IB_QP_PKEY_INDEX)
> > > > > - new_pps->main.pkey_index = (qp_pps) ? qp_pps-
> > > > > >main.pkey_index :
> > > > > - qp_attr-
> >pkey_index;
> > > > > + new_pps->main.pkey_index = qp_attr->pkey_index;
> > > > > + else if (qp_pps)
> > > > > + new_pps->main.pkey_index = qp_pps-
> >main.pkey_index;
> > > > > +
> > > > > if ((qp_attr_mask & IB_QP_PKEY_INDEX) && (qp_attr_mask
> &
> > > > > IB_QP_PORT))
> > > > > new_pps->main.state = IB_PORT_PKEY_VALID;
> > > > >
> > > >
> > > > I agree with this aspect of the patch and it does fix the panic, because
> the
> > > correct unit
> > > > is gotten from qp_pps.
> > > >
> > > > My issue is that the new_pps->main.state will come back as 0, and the
> > > insert routine will drop any new pkey index update.
> > > >
> > > > The sequence I'm concerned about is:
> > > >
> > > > 0x71 attr mask with both pkey index and port.
> > > >
> > > > A ulp decides to change the pkey index and does an 0x51 modify
> without
> > > setting the unit.
> > > >
> > > > I see new_pps->main.state being returned as 0 and
> port_pkey_list_insert()
> > > will early out.
> > >
> > > I see, maybe we can store the main.state in qps and restore it from
> there?
> > >
> >
> > I don't think we need to go that far.
> >
> > I think all we need to do is
> >
> > if ((qp_attr_mask & IB_QP_PKEY_INDEX) && (qp_attr_mask &
> IB_QP_PORT))
> > new_pps->main.state = IB_PORT_PKEY_VALID;
> > else if ((qp_attr_mask & (IB_QP_PKEY_INDEX | IB_QP_PORT)) &&
> qp_pps) {
> > /*
> > * one of the attributes modified and already copied above.
> > *
> > * correct the state based on qp_pps state
> > */
> > if (qp_pps->main.state != IB_PORT_PKEY_NOT_VALID)
> > new_pps->main.state = IB_PORT_PKEY_VALID;
> > }
> >
> > I'm ok will a follow-up patch after Maor's patch to fix remaining issues.
>
> Are you then OK with the patch Maor posted? Please add a tag. I'm
> waiting for you :)
>
Yes, I'm ok with Maor's patch. It certainly fixes the panic.
I will try the above approach in a subsequent patch.
Tested-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Mike
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in get_new_pps
2020-02-27 12:57 [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in get_new_pps Leon Romanovsky
2020-02-27 14:07 ` Marciniszyn, Mike
@ 2020-02-28 15:23 ` Jason Gunthorpe
1 sibling, 0 replies; 7+ messages in thread
From: Jason Gunthorpe @ 2020-02-28 15:23 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: Doug Ledford, Maor Gottlieb, linux-rdma
On Thu, Feb 27, 2020 at 02:57:28PM +0200, Leon Romanovsky wrote:
> From: Maor Gottlieb <maorg@mellanox.com>
>
> When port is part of the modify mask, then we should take
> it from the qp_attr and not from the old pps. Same for PKEY.
>
> Cc: <stable@vger.kernel.org>
> Fixes: 1dd017882e01 ("RDMA/core: Fix protection fault in get_pkey_idx_qp_list")
> Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> drivers/infiniband/core/security.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
Applied to for-rc, thanks
Jason
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-02-28 15:23 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-27 12:57 [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in get_new_pps Leon Romanovsky
2020-02-27 14:07 ` Marciniszyn, Mike
2020-02-27 19:01 ` Leon Romanovsky
2020-02-27 22:49 ` Marciniszyn, Mike
2020-02-28 15:02 ` Jason Gunthorpe
2020-02-28 15:12 ` Marciniszyn, Mike
2020-02-28 15:23 ` Jason Gunthorpe
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.