From: Jason Gunthorpe <jgg@nvidia.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Leon Romanovsky <leon@kernel.org>,
Doug Ledford <dledford@redhat.com>,
Avihai Horon <avihaih@nvidia.com>,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org
Subject: Re: [PATCH rdma-next v1 2/2] RDMA/mlx5: Allow modifying Relaxed Ordering via fast registration
Date: Thu, 27 May 2021 11:57:10 -0300 [thread overview]
Message-ID: <20210527145710.GF1002214@nvidia.com> (raw)
In-Reply-To: <YK992cLoTRWG30H9@infradead.org>
On Thu, May 27, 2021 at 12:09:13PM +0100, Christoph Hellwig wrote:
> 1) qp_access_flags as a bitmask of possible operations on the queue pair
> The way I understood the queue pairs this should really be just bits
> for remote read, remote write and atomics, but a few places also
> mess with memory windows and local write, which seems to be some
> sort of iWarp cludge
Honestly I'm not completely sure what the QP access flags are for
anymore, will have to go look at some point.
> 2) IB_UVERBS_ACCESS_*. These just get checked using ib_check_mr_access
> and then passed into ->reg_user_mr, ->rereg_user_mr and
> ->reg_user_mr_dmabuf
Yes. Using the kernerl flags for those user marked APIs is intended to
simplify the drivers as the user/kernel MR logic should have shared
elements
> 3) in-kernel FRWR uses IB_ACCESS_*, but all users seem to hardcode it
> to IB_ACCESS_LOCAL_WRITE | IB_ACCESS_REMOTE_READ |
> IB_ACCESS_REMOTE_WRITE anyway
So when a ULP is processing a READ it doesn't create a FRWR with
read-only rights? Isn't that security wrong?
Jason
next prev parent reply other threads:[~2021-05-27 14:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-20 10:13 [PATCH rdma-next v1 0/2] Enable relaxed ordering for ULPs Leon Romanovsky
2021-05-20 10:13 ` [PATCH rdma-next v1 1/2] RDMA: Enable Relaxed Ordering by default for kernel ULPs Leon Romanovsky
2021-05-27 10:28 ` Christoph Hellwig
2021-05-28 18:27 ` Jason Gunthorpe
2021-05-20 10:13 ` [PATCH rdma-next v1 2/2] RDMA/mlx5: Allow modifying Relaxed Ordering via fast registration Leon Romanovsky
2021-05-26 19:49 ` Jason Gunthorpe
2021-05-27 11:09 ` Christoph Hellwig
2021-05-27 14:57 ` Jason Gunthorpe [this message]
2021-05-27 15:06 ` Christoph Hellwig
2021-06-02 12:16 ` Leon Romanovsky
2021-05-26 19:30 ` [PATCH rdma-next v1 0/2] Enable relaxed ordering for ULPs Jason Gunthorpe
2021-05-27 8:11 ` David Laight
2021-05-31 18:13 ` Jason Gunthorpe
2021-05-31 21:45 ` David Laight
2021-05-31 22:44 ` 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=20210527145710.GF1002214@nvidia.com \
--to=jgg@nvidia.com \
--cc=avihaih@nvidia.com \
--cc=dledford@redhat.com \
--cc=hch@infradead.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
/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.