Intel-XE Archive on lore.kernel.org
 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 23/23] dma-buf: Add kunit tests for mapping type selection
Date: Fri, 06 Nov 2026 06:44:01 +0000	[thread overview]
Message-ID: <sashiko-outbox-200939@kernel.org> (raw)
In-Reply-To: <20261105-dma_mapping_type_v4-v2-23-78b8dc9ae80a@nvidia.com>

Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [Low] dma-buf: duplicate KUNIT_EXPECT_PTR_EQ() added in
  test_mock_attach()
- [Low] dma-buf: duplicated callback setup and dead field in
  mock_mapping
- [Low] dma-buf: commit message omits failed map and pin selection tests
--

commit 71d342095c556fe9ee3e5b69defcc3e410afbe6f
Author: Alistair Popple <apopple@nvidia.com>

dma-buf: Add kunit tests for mapping type selection

This commit adds a configurable offer list, a select_mapping() callback, and
map/unmap operations for the mock mapping types in the dma-buf KUnit test
suite. It also introduces new KUnit test cases to verify the mapping type
selection contract across attach, map, pin, and failure paths.

>     dma-buf: Add kunit tests for mapping type selection
>     
>     Add an offer list and a select_mapping() callback to the mock exporter
>     along with map/unmap for the two mock types.
>     
>     Adds tests for the exporter/importer contract.
>     
>      - test_match_set_is_final: a later importer attaching, even one the
>        exporter answers differently, does not change an existing
>        attachment's match set or default. Later attachments influence what
>        the exporter selects at pin and map time, not previous attachments.
>     
>      - test_select_at_map: the exporter chooses a non-default entry
>        at the first map and the result is tagged with it. A pin taken
>        under the live mapping inherits the type and the choice survives
>        unmap/remap even though the exporter would answer differently. Only
>        dma_buf_invalidate_mappings() allows the exporter to make a different
>        selection. An -EBUSY from selection leaves nothing established.
>     
>      - test_select_at_pin: pin selects, and the choice survives map, unmap
>        and unpin so a pinned importer that is never invalidated keeps its
>        first type for the life of the import.
>     
>     Signed-off-by: Alistair Popple <apopple@nvidia.com>

[Severity: Low]
This isn't a bug, but the commit message only lists test_match_set_is_final,
test_select_at_map, and test_select_at_pin, while the patch also adds
mock_dmabuf_pin(), mock_dmabuf_unpin(), failure injection state, and two
additional test cases in dma_mapping_cases (test_select_survives_failed_map
and test_select_after_failed_pin).

Could the commit message be updated to describe these two failed map and pin
selection tests as well?

> diff --git a/drivers/dma-buf/st-dma-mapping.c b/drivers/dma-buf/st-dma-mapping.c
> index cbfa99aeb0ff5..11010731150ae 100644
> --- a/drivers/dma-buf/st-dma-mapping.c
> +++ b/drivers/dma-buf/st-dma-mapping.c

[ ... ]

> @@ -370,11 +391,478 @@ static void test_mock_attach(struct kunit *test)
>  	KUNIT_EXPECT_PTR_EQ(test, dma_buf_attach_map_type(attach)->type,
>  			    &mock_type_a);
>  	KUNIT_EXPECT_PTR_EQ(test, mock_match_dev_arg, dev);
> +	KUNIT_EXPECT_PTR_EQ(test, mock_match_dev_arg, dev);

[Severity: Low]
This isn't a bug, but was this second KUNIT_EXPECT_PTR_EQ(test,
mock_match_dev_arg, dev) in test_mock_attach() added by accident?

[ ... ]

> +/* Mock mapping result for the generic map path */
> +struct mock_mapping {
> +	struct dma_buf_mapping base;
> +	const struct dma_buf_mapping_type *made_by;
> +};
> +
> +static struct dma_buf_mapping *mock_type_map(struct dma_buf_attachment *attach,
> +					     enum dma_data_direction dir)
> +{
> +	struct mock_mapping *m;
> +
> +	if (mock_map_err)
> +		return ERR_PTR(mock_map_err);
> +	m = kzalloc_obj(*m);
> +	if (!m)
> +		return ERR_PTR(-ENOMEM);
> +	m->base.type = dma_buf_attach_map_type(attach)->type;
> +	m->made_by = dma_buf_attach_map_type(attach)->type;
> +	return &m->base;
> +}

[ ... ]

> +static void test_select_at_map(struct kunit *test)
> +{
> +	static const struct dma_buf_mapping_match offer_ab[] = {
> +		{ .type = &mock_type_a },
> +		{ .type = &mock_type_b },
> +	};
> +	struct dma_buf_mapping_match imp[] = {
> +		{ .type = &mock_type_a },
> +		{ .type = &mock_type_b },
> +	};
> +	MOCK_IMPORTER_OPS(importer_ops, imp);
> +	struct dma_buf_attachment *attach;
> +	struct dma_buf_mapping *mapping;
> +	struct dma_buf *dmabuf;
> +	struct device *dev;
> +
> +	mock_type_a.map = mock_type_map;
> +	mock_type_a.unmap = mock_type_unmap;
> +	mock_type_b.map = mock_type_map;
> +	mock_type_b.unmap = mock_type_unmap;

[Severity: Low]
This isn't a bug, but test_select_at_map(), test_select_at_pin(),
test_select_survives_failed_map(), and test_select_after_failed_pin() each
manually assign map and unmap on mock_type_a and mock_type_b at the start of
the test and clear them to NULL at the end. If any KUNIT_ASSERT_NOT_ERR_OR_NULL
in those tests fails, the test aborts before clearing the pointers and
reset_mock_state() does not reset them.

Since none of the other tests in drivers/dma-buf/st-dma-mapping.c require
mock_type_a.map or mock_type_b.map to be NULL, could map and unmap be
initialized directly in the static definitions of mock_type_a and mock_type_b
instead? Also, is the made_by field in struct mock_mapping needed given that
mock_type_map() sets m->base.type to the same value and made_by is never read?

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

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

Thread overview: 31+ 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-05  6:40 ` [PATCH v2 02/23] dma-buf: Introduce DMA-buf mapping types Alistair Popple
2026-11-05  6:40 ` [PATCH v2 03/23] dma-buf: Add the SGT DMA mapping type Alistair Popple
2026-11-05  6:40 ` [PATCH v2 04/23] dma-buf: Negotiate the mapping type in dma_buf_dynamic_attach() Alistair Popple
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-05  6:40 ` [PATCH v2 06/23] dma-buf: Let the exporter select mapping type at pin/map Alistair Popple
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-05  6:40 ` [PATCH v2 08/23] dma-buf: Add dma_buf_mapping_map() returning a type-tagged mapping Alistair Popple
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-05  6:40 ` [PATCH v2 10/23] drm: Check the SGT ops for drm_gem_map_dma_buf() Alistair Popple
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-05  6:40 ` [PATCH v2 12/23] drm/vmwgfx: Use match_mapping instead of dummy calls Alistair Popple
2026-11-05  6:40 ` [PATCH v2 13/23] accel/habanalabs: Use the SGT_P2P mapping type Alistair Popple
2026-11-05  6:40 ` [PATCH v2 14/23] drm/xe/dma-buf: Use the SGT " Alistair Popple
2026-11-05  6:40 ` [PATCH v2 15/23] drm/amdgpu: " Alistair Popple
2026-11-05  6:40 ` [PATCH v2 16/23] vfio/pci: Change the DMA-buf exporter to use mapping_type Alistair Popple
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
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-05  6:40 ` [PATCH v2 19/23] iio: buffer: convert " Alistair Popple
2026-11-05  6:40 ` [PATCH v2 20/23] functionfs: " Alistair Popple
2026-11-05  6:40 ` [PATCH v2 21/23] dma-buf: Remove unused SGT stuff from the common structures Alistair Popple
2026-11-05  6:40 ` [PATCH v2 22/23] dma-buf: Add kunit tests for mapping type Alistair Popple
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 [this message]
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-200939@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