On 2026-09-24 8:55 AM, Yili Zhang wrote:
The dma_buf_phys_vec_to_sgt() routine links every physical range into the allocated IOVA space at offset zero instead of advancing the offset by the already mapped length. This breaks the THRU_HOST_BRIDGE flow whenever phys_vec contains more than one entry: the second and subsequent dma_iova_link() calls try to install mappings on top of PTEs that already exist, which fails and makes the whole conversion return an error.Fix it by passing the accumulated mapped_len as the IOVA offset. This matches the pattern used by all other dma_iova_link() callers and is consistent with the rest of the function: dma_iova_sync() and the error path in dma_iova_destroy() both operate on the [0, mapped_len) prefix of the IOVA space, which assumes that the ranges were linked contiguously starting at offset 0. Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Cc: [email protected]
Reviewed-by: Dawid Osuchowski <[email protected]>
Signed-off-by: Yili Zhang <[email protected]> --- drivers/dma-buf/dma-buf-mapping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 833be519e1e6..ef0f22854d01 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -156,7 +156,7 @@ struct sg_table *dma_buf_phys_vec_to_sgt(struct dma_buf_attachment *attach, phys_vec[i].paddr); } else if (dma_use_iova(dma->state)) { ret = dma_iova_link(attach->dev, dma->state, - phys_vec[i].paddr, 0, + phys_vec[i].paddr, mapped_len, phys_vec[i].len, dir, DMA_ATTR_MMIO); if (ret)
