From: Jason Gunthorpe <jgg@nvidia.com>
To: "Daisuke Matsuda (Fujitsu)" <matsuda-daisuke@fujitsu.com>
Cc: "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"leonro@nvidia.com" <leonro@nvidia.com>,
"zyjzyj2000@gmail.com" <zyjzyj2000@gmail.com>,
"lizhijian@fujitsu.com" <lizhijian@fujitsu.com>,
"rpearsonhpe@gmail.com" <rpearsonhpe@gmail.com>
Subject: Re: [PATCH] Revert "RDMA/rxe: Remove unnecessary mr testing"
Date: Thu, 8 Dec 2022 08:23:50 -0400 [thread overview]
Message-ID: <Y5HXVisxlA2MsXT/@nvidia.com> (raw)
In-Reply-To: <TYCPR01MB8455576D21C033F8694EA5A8E51D9@TYCPR01MB8455.jpnprd01.prod.outlook.com>
On Thu, Dec 08, 2022 at 06:08:30AM +0000, Daisuke Matsuda (Fujitsu) wrote:
> On Thu, Dec 8, 2022 8:44 AM Jason Gunthorpe wrote:
> >
> > On Fri, Dec 02, 2022 at 08:01:57PM +0900, Daisuke Matsuda wrote:
> > > The commit 686d348476ee ("RDMA/rxe: Remove unnecessary mr testing") causes
> > > a kernel crash. If responder get a zero-byte RDMA Read request, qp->resp.mr
> > > is not set in check_rkey(). The mr is NULL in this case, and a NULL pointer
> > > dereference occurs as shown below.
> >
> > I don't think this is right.
> >
> > What justification is there for not validating the rkey in check_rkey
> > just because the length is 0?
>
> I referred to IB Specification Vol 1-Release-1.5-2021-08-06b.
> The behaviour of responder on receiving a packet is described in "9.7.4.1".
> The current implementation of check_rkey() is justified by "9.7.4.1.5 C9-88".
>
> >
> > IBA 9.3.3.2 says:
> >
> > <...>
>
> The document is proprietary. I think it is safer not to quote the contents,
> so I do not show what "9.7.4.1.5 C9-88" says here.
> Sorry for bothering you, but please check the description by
> yourself.
Well, that seems clear enough. Let's reference C9-88 in this patch as
well
Jason
prev parent reply other threads:[~2022-12-08 12:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-02 11:01 [PATCH] Revert "RDMA/rxe: Remove unnecessary mr testing" Daisuke Matsuda
2022-12-02 11:45 ` Zhu Yanjun
2022-12-02 14:35 ` lizhijian
2022-12-02 14:43 ` Jason Gunthorpe
2022-12-05 5:19 ` Daisuke Matsuda (Fujitsu)
2022-12-07 23:43 ` Jason Gunthorpe
2022-12-08 6:08 ` Daisuke Matsuda (Fujitsu)
2022-12-08 12:23 ` Jason Gunthorpe [this message]
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=Y5HXVisxlA2MsXT/@nvidia.com \
--to=jgg@nvidia.com \
--cc=leonro@nvidia.com \
--cc=linux-rdma@vger.kernel.org \
--cc=lizhijian@fujitsu.com \
--cc=matsuda-daisuke@fujitsu.com \
--cc=rpearsonhpe@gmail.com \
--cc=zyjzyj2000@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.