From: Jason Gunthorpe <jgg@mellanox.com>
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" <linux-rdma@vger.kernel.org>
Subject: Re: [PATCH rdma-rc] RDMA/core: Fix pkey and port assignment in get_new_pps
Date: Fri, 28 Feb 2020 11:02:44 -0400 [thread overview]
Message-ID: <20200228150244.GT26318@mellanox.com> (raw)
In-Reply-To: <MWHPR1101MB227182E4E00015AD2850AFF486EB0@MWHPR1101MB2271.namprd11.prod.outlook.com>
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
next prev parent reply other threads:[~2020-02-28 15:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2020-02-28 15:12 ` Marciniszyn, Mike
2020-02-28 15:23 ` Jason Gunthorpe
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=20200228150244.GT26318@mellanox.com \
--to=jgg@mellanox.com \
--cc=dledford@redhat.com \
--cc=leon@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=maorg@mellanox.com \
--cc=mike.marciniszyn@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox