From: Jason Gunthorpe <jgg@ziepe.ca>
To: Joel Nider <joeln@il.ibm.com>
Cc: Leon Romanovsky <leon@kernel.org>,
Doug Ledford <dledford@redhat.com>,
Mike Rapoport <rppt@linux.ibm.com>,
linux-mm@kvack.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/5] RDMA/uverbs: add owner parameter to ib_umem_get
Date: Tue, 29 Jan 2019 09:56:19 -0700 [thread overview]
Message-ID: <20190129165619.GC10094@ziepe.ca> (raw)
In-Reply-To: <1548768386-28289-4-git-send-email-joeln@il.ibm.com>
On Tue, Jan 29, 2019 at 03:26:24PM +0200, Joel Nider wrote:
> ib_umem_get is a core function used by drivers that support RDMA.
> The 'owner' parameter signifies the process that owns the memory.
> Until now, it was assumed that the owning process was the current
> process. This adds the flexibility to specify a process other than
> the current process. All drivers that call this function are also
> updated, but the default behaviour is to keep backwards
> compatibility by assuming the current process is the owner when
> the 'owner' parameter is NULL.
>
> Signed-off-by: Joel Nider <joeln@il.ibm.com>
> drivers/infiniband/core/umem.c | 26 ++++++++++++++++++++------
> drivers/infiniband/hw/bnxt_re/ib_verbs.c | 10 +++++-----
> drivers/infiniband/hw/cxgb3/iwch_provider.c | 3 ++-
> drivers/infiniband/hw/cxgb4/mem.c | 3 ++-
> drivers/infiniband/hw/hns/hns_roce_cq.c | 2 +-
> drivers/infiniband/hw/hns/hns_roce_db.c | 2 +-
> drivers/infiniband/hw/hns/hns_roce_mr.c | 4 ++--
> drivers/infiniband/hw/hns/hns_roce_qp.c | 2 +-
> drivers/infiniband/hw/hns/hns_roce_srq.c | 2 +-
> drivers/infiniband/hw/i40iw/i40iw_verbs.c | 2 +-
> drivers/infiniband/hw/mlx4/cq.c | 2 +-
> drivers/infiniband/hw/mlx4/doorbell.c | 2 +-
> drivers/infiniband/hw/mlx4/mr.c | 2 +-
> drivers/infiniband/hw/mlx4/qp.c | 2 +-
> drivers/infiniband/hw/mlx4/srq.c | 2 +-
> drivers/infiniband/hw/mlx5/cq.c | 4 ++--
> drivers/infiniband/hw/mlx5/devx.c | 2 +-
> drivers/infiniband/hw/mlx5/doorbell.c | 2 +-
> drivers/infiniband/hw/mlx5/mr.c | 15 ++++++++-------
> drivers/infiniband/hw/mlx5/odp.c | 5 +++--
> drivers/infiniband/hw/mlx5/qp.c | 4 ++--
> drivers/infiniband/hw/mlx5/srq.c | 2 +-
> drivers/infiniband/hw/mthca/mthca_provider.c | 2 +-
> drivers/infiniband/hw/nes/nes_verbs.c | 3 ++-
> drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 3 ++-
> drivers/infiniband/hw/qedr/verbs.c | 8 +++++---
> drivers/infiniband/hw/vmw_pvrdma/pvrdma_cq.c | 2 +-
> drivers/infiniband/hw/vmw_pvrdma/pvrdma_mr.c | 2 +-
> drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c | 5 +++--
> drivers/infiniband/hw/vmw_pvrdma/pvrdma_srq.c | 2 +-
> drivers/infiniband/sw/rdmavt/mr.c | 2 +-
> drivers/infiniband/sw/rxe/rxe_mr.c | 3 ++-
> include/rdma/ib_umem.h | 3 ++-
> 33 files changed, 80 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
> index c6144df..9646cee 100644
> +++ b/drivers/infiniband/core/umem.c
> @@ -71,15 +71,21 @@ static void __ib_umem_release(struct ib_device *dev, struct ib_umem *umem, int d
> *
> * If access flags indicate ODP memory, avoid pinning. Instead, stores
> * the mm for future page fault handling in conjunction with MMU notifiers.
> + * If the process doing the pinning is the same as the process that owns
> + * the memory being pinned, 'owner' should be NULL. Otherwise, 'owner' should
> + * be the process ID of the owning process. The process ID must be in the
> + * same PID namespace as the calling userspace context.
> *
> - * @context: userspace context to pin memory for
> + * @context: userspace context that is pinning the memory
> * @addr: userspace virtual address to start at
> * @size: length of region to pin
> * @access: IB_ACCESS_xxx flags for memory being pinned
> * @dmasync: flush in-flight DMA when the memory region is written
> + * @owner: the ID of the process that owns the memory being pinned
> */
> struct ib_umem *ib_umem_get(struct ib_ucontext *context, unsigned long addr,
> - size_t size, int access, int dmasync)
> + size_t size, int access, int dmasync,
> + struct pid *owner)
You need to rebase this patch on rdma's for-next tree, the signature is
different.
Jason
next prev parent reply other threads:[~2019-01-29 16:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-29 13:26 [PATCH 0/5] RDMA: reg_remote_mr Joel Nider
2019-01-29 13:26 ` [PATCH 1/5] mm: add get_user_pages_remote_longterm function Joel Nider
2019-01-29 13:26 ` [PATCH 2/5] RDMA/uverbs: add owner parameter to reg_user_mr Joel Nider
2019-01-29 13:26 ` [PATCH 3/5] RDMA/uverbs: add owner parameter to ib_umem_get Joel Nider
2019-01-29 16:56 ` Jason Gunthorpe [this message]
2019-01-29 18:29 ` Ira Weiny
2019-01-29 13:26 ` [PATCH 4/5] RDMA/uverbs: add owner parameter to ib_umem_odp_get Joel Nider
2019-01-29 13:26 ` [PATCH 5/5] RDMA/uverbs: add UVERBS_METHOD_REG_REMOTE_MR Joel Nider
2019-01-29 17:04 ` Jason Gunthorpe
2019-01-30 8:34 ` Joel Nider
2019-01-30 21:23 ` Jason Gunthorpe
2019-01-29 16:44 ` [PATCH 0/5] RDMA: reg_remote_mr Steve Wise
2019-01-29 18:34 ` Ira Weiny
2019-01-30 8:22 ` Joel Nider
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=20190129165619.GC10094@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=dledford@redhat.com \
--cc=joeln@il.ibm.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rdma@vger.kernel.org \
--cc=rppt@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).