Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Alistair Popple" <apopple@nvidia.com>,
	dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	linux-rdma@vger.kernel.org, linux-nvme@lists.infradead.org
Cc: media-ci@linuxtv.org
Subject: Re: [PATCH v2 17/23] RDMA/uverbs: Use the SGT_P2P mapping type
Date: Fri, 06 Nov 2026 06:43:57 +0000	[thread overview]
Message-ID: <sashiko-outbox-200933@kernel.org> (raw)
In-Reply-To: <20261105-dma_mapping_type_v4-v2-17-78b8dc9ae80a@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] RDMA/uverbs: commit message contradicts
  uverbs_dmabuf_match_mapping()
--

commit f919774da72af458231453cd6f22c8076d245156
Author: Jason Gunthorpe <jgg@ziepe.ca>

RDMA/uverbs: Use the SGT_P2P mapping type

This commit converts uverbs dmabuf from an attach callback checking
attachment->peer2peer to a match_mapping callback using
DMA_BUF_EMAPPING_SGT_REQUIRES_P2P().

>     RDMA/uverbs: Use the SGT_P2P mapping type
>     
>     Very similar to habana, except the rejection of unsupported
>     pci_p2p_dma_distance() is done inside map not attach via
>     dma_buf_phys_vec_to_sgt().
>     
>     Convert this directly to a SGT_P2P match which will prevent matching if
>     dma_buf_phys_vec_to_sgt() would fail.
>     
>     Remove the now empty attach function.
>     
>     Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
>     Signed-off-by: Alistair Popple <apopple@nvidia.com>
> 
> diff --git a/drivers/infiniband/core/uverbs_std_types_dmabuf.c b/drivers/infiniband/core/uverbs_std_types_dmabuf.c
> index 8d8c997a48834..0bae578c3d78e 100644
> --- a/drivers/infiniband/core/uverbs_std_types_dmabuf.c
> +++ b/drivers/infiniband/core/uverbs_std_types_dmabuf.c

[ ... ]

> @@ -95,13 +86,30 @@ static void uverbs_dmabuf_release(struct dma_buf *dmabuf)
>  	uverbs_uobject_put(&priv->uobj);
>  }
>  
> -static const struct dma_buf_ops uverbs_dmabuf_ops = {
> -	.attach = uverbs_dmabuf_attach,
> +static const struct dma_buf_mapping_sgt_exp_ops uverbs_dma_buf_sgt_ops = {
>  	.map_dma_buf = uverbs_dmabuf_map,
>  	.unmap_dma_buf = uverbs_dmabuf_unmap,
> +};
> +
> +static int uverbs_dmabuf_match_mapping(struct dma_buf_match_args *args)
> +{
> +	struct dma_buf_mapping_match sgt_match[1];
> +
> +	/*
> +	 * MMIO, so the importer must accept P2P. The provider is only valid
> +	 * under the dma_resv lock while not revoked, so the distance check is
> +	 * left to dma_buf_phys_vec_to_sgt() at map time, as before.
> +	 */
> +	sgt_match[0] = DMA_BUF_EMAPPING_SGT_REQUIRES_P2P(&uverbs_dma_buf_sgt_ops);

[Severity: Medium]
Does the commit message match the implementation in
uverbs_dmabuf_match_mapping()?

The commit title and changelog state that this converts uverbs to a SGT_P2P
match which prevents matching if dma_buf_phys_vec_to_sgt() would fail due to
an unsupported pci_p2p_dma_distance().

However, uverbs_dmabuf_match_mapping() uses
DMA_BUF_EMAPPING_SGT_REQUIRES_P2P() rather than DMA_BUF_EMAPPING_SGT_P2P().
As noted in the code comment, DMA_BUF_EMAPPING_SGT_REQUIRES_P2P() only checks
that the importer accepts P2P (replacing the !attachment->peer2peer check in
uverbs_dmabuf_attach()) and leaves the P2P distance check to
dma_buf_phys_vec_to_sgt() at map time because priv->provider is only valid
under the dma_resv lock while not revoked.

Should the commit title and message be updated to reflect that
DMA_BUF_EMAPPING_SGT_REQUIRES_P2P() is used instead of SGT_P2P, and that the
distance check remains at map time?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261105-dma_mapping_type_v4-v2-0-78b8dc9ae80a@nvidia.com?part=17

  reply	other threads:[~2026-11-06  6:43 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-05  6:40 [PATCH v2 00/23] DMA-buf mapping types Alistair Popple
2026-11-05  6:40 ` [PATCH v2 01/23] treewide: Rename dma_buf_(un)map_attachment() to dma_buf_(un)map_sgt() Alistair Popple
2026-11-05  9:55   ` Christian König
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 02/23] dma-buf: Introduce DMA-buf mapping types Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 03/23] dma-buf: Add the SGT DMA mapping type Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 04/23] dma-buf: Negotiate the mapping type in dma_buf_dynamic_attach() Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 05/23] dma-buf: Route SGT related actions through the attachment's mapping type Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 06/23] dma-buf: Let the exporter select mapping type at pin/map Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-07  8:57   ` Karl Mehltretter
2026-11-09  2:58     ` Alistair Popple
2026-11-09 10:59       ` Christian König
2026-11-05  6:40 ` [PATCH v2 07/23] dma-buf: Add match set queries for exporter placement decisions Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 08/23] dma-buf: Add dma_buf_mapping_map() returning a type-tagged mapping Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 09/23] dma-buf: Allow single exporter drivers to avoid the match_mapping function Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 10/23] drm: Check the SGT ops for drm_gem_map_dma_buf() Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 11/23] dma-buf: Convert all the simple exporters to use SGT mapping type Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 12/23] drm/vmwgfx: Use match_mapping instead of dummy calls Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 13/23] accel/habanalabs: Use the SGT_P2P mapping type Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 14/23] drm/xe/dma-buf: Use the SGT " Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 15/23] drm/amdgpu: " Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 16/23] vfio/pci: Change the DMA-buf exporter to use mapping_type Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 17/23] RDMA/uverbs: Use the SGT_P2P mapping type Alistair Popple
2026-11-06  6:43   ` sashiko-bot [this message]
2026-11-05  6:40 ` [PATCH v2 18/23] dma-buf: Update dma_buf_phys_vec_to_sgt() to use the SGT " Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 19/23] iio: buffer: convert " Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 20/23] functionfs: " Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 21/23] dma-buf: Remove unused SGT stuff from the common structures Alistair Popple
2026-11-06  6:43   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 22/23] dma-buf: Add kunit tests for mapping type Alistair Popple
2026-11-06  6:44   ` sashiko-bot
2026-11-05  6:40 ` [PATCH v2 23/23] dma-buf: Add kunit tests for mapping type selection Alistair Popple
2026-11-06  6:44   ` sashiko-bot
2026-11-05 16:18 ` [PATCH v2 00/23] DMA-buf mapping types Maarten Lankhorst

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=sashiko-outbox-200933@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=apopple@nvidia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=media-ci@linuxtv.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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