Re: [RFC PATCH 5/6] selftests/vfio: Accept sPAPR errno for DMA range overflow

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Architecture-specific macro breaks test execution with alternative IOMMU backends on PowerPC.
- [Medium] The test's expectation of `-ENXIO` codifies and relies upon an integer overflow bug in the test library's user-space validation helper.
--

commit 93dbee7bb3c363a49eb5141c94b3669c7520cd26
Author: Narayana Murty N <nnmlinux@linux.ibm.com>

selftests/vfio: Accept sPAPR errno for DMA range overflow

The DMA map limit test expects an overflowing IOVA range to fail with
-EOVERFLOW. This commit modifies the test to expect -ENXIO when compiled
for powerpc to account for sPAPR TCE v2 rejecting the range as outside
the active TCE window.

> diff --git a/tools/testing/selftests/vfio/vfio_dma_mapping_test.c b/tools/testing/selftests/vfio/vfio_dma_mapping_test.c
> index 4411fdbd56da5..cd2d3276a46c4 100644
> --- a/tools/testing/selftests/vfio/vfio_dma_mapping_test.c
> +++ b/tools/testing/selftests/vfio/vfio_dma_mapping_test.c
> @@ -316,10 +316,18 @@ TEST_F(vfio_dma_map_limit_test, overflow)
>  	region->size = self->mmap_size;
>  
>  	rc = __iommu_map(self->iommu, region);
> +#ifdef __powerpc__
> +	ASSERT_EQ(rc, -ENXIO);

[Severity: Medium]
Will this architecture-specific macro break test execution if an alternative
IOMMU backend is used on PowerPC?

Since earlier patches in this series allow selecting the IOMMU backend via
the VFIO_SELFTESTS_IOMMU_MODE environment variable, running the test on
PowerPC with iommufd would return the generic -EOVERFLOW error. Because of
the #ifdef, the test would erroneously expect -ENXIO and fail.

Would it be better to base this branch on the active backend type (e.g.,
inspecting variant->iommu_mode) rather than the compilation target?

[Severity: Medium]
Does expecting -ENXIO here codify a bug in the user-space validation
helper?

In the overflow test, the region->iova is set to a large value so that
region->iova + region->size wraps around to 0.

Looking at spapr_tce_iova_inside_window() introduced earlier in the series,
it evaluates:

tools/testing/selftests/vfio/lib/iommu.c:spapr_tce_iova_inside_window() {
    ...
    if (region->iova + region->size > window->start + window->size)
        return false;
    ...
}

Due to the wrap-around, 0 > 0 + window->size evaluates to false, causing
the validation helper to return true. This bypasses user-space validation,
allowing the invalid IOVA to be sent to the kernel via VFIO_IOMMU_MAP_DMA,
which then rejects it with -ENXIO.

If the user-space bounds check is fixed to catch wrap-arounds (for example,
checking if region->iova + region->size < region->iova), the helper would
correctly return false and the user-space map attempt would return -EINVAL.

Would that fix cause this test to fail because it now explicitly expects
-ENXIO?

> +#else
>  	ASSERT_EQ(rc, -EOVERFLOW);
> +#endif
>  
>  	rc = __iommu_unmap(self->iommu, region, NULL);
> +#ifdef __powerpc__
> +	ASSERT_EQ(rc, -ENXIO);
> +#else
>  	ASSERT_EQ(rc, -EOVERFLOW);
> +#endif
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703032806.40946-1-nnmlinux@linux.ibm.com?part=5