Re: [PATCH 1/2] fpga: Add dma-buf interface for FPGA programming

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] Passing a DMA-mapped dma-buf scatterlist to the FPGA manager core causes double-mapping or CPU access of device memory, triggering kernel panics.
- [High] The FPGA_IOCTL_LOAD_DMA_BUF ioctl lacks a firmware size parameter, causing the full page-aligned dma-buf capacity to be pushed into the FPGA port, corrupting configuration.
--

--- Patch [1]: [PATCH 1/2] fpga: Add dma-buf interface for FPGA programming ---
commit 9a25ee19d33999a56fc7670a1a9dbec98cb947aa
Author: Aravind Thokala <[email protected]>

fpga: Add dma-buf interface for FPGA programming

This commit adds a module that allows userspace to pass a pre-allocated DMA
buffer directly to the FPGA manager via ioctl. It creates a miscdevice for
each FPGA manager that registers dma-buf support to map and load the image
without an extra memory copy.

> diff --git a/drivers/fpga/fpga-dmabuf.c b/drivers/fpga/fpga-dmabuf.c
> new file mode 100644
> index 0000000000000..0e92eb1346981
> --- /dev/null
> +++ b/drivers/fpga/fpga-dmabuf.c

[ ... ]

> +static int fpga_dmabuf_load(struct fpga_manager *mgr, int buffd)
> +{
> +	struct fpga_image_info *info;
> +	struct dma_buf_attachment *attach;
> +	struct dma_buf *dmabuf;
> +	struct sg_table *sgt;
> +	int ret;

[ ... ]

> +	sgt = dma_buf_map_attachment_unlocked(attach, DMA_TO_DEVICE);
> +	if (IS_ERR(sgt)) {
> +		ret = PTR_ERR(sgt);
> +		goto err_detach;
> +	}
> +
> +	info->sgt = sgt;
> +
> +	ret = fpga_mgr_lock(mgr);
> +	if (ret)
> +		goto err_unmap;
> +
> +	ret = fpga_mgr_load(mgr, info);

[Severity: Critical]
Does passing a DMA-mapped sg_table into fpga_mgr_load() cause issues with the
underlying FPGA manager drivers?

Hardware drivers typically expect an unmapped CPU sg_table and will call
dma_map_sgtable() on it. Calling dma_map_sgtable() on an already mapped
sg_table can overwrite DMA addresses and corrupt the DMA state.

Additionally, the core manager may fall back to CPU PIO to read the image
header via sg_miter (which internally uses kmap). If the dma-buf is backed
by P2P device memory, this could dereference invalid struct pages and cause
a kernel panic. It also bypasses cache coherency since
dma_buf_begin_cpu_access() is never called.

[ ... ]

> diff --git a/include/uapi/linux/fpga.h b/include/uapi/linux/fpga.h
> new file mode 100644
> index 0000000000000..868650c66526b
> --- /dev/null
> +++ b/include/uapi/linux/fpga.h
> @@ -0,0 +1,15 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/*
> + * FPGA userspace API
> + *
> + * Copyright (C) 2026 Advanced Micro Devices, Inc.
> + */
> +#ifndef _UAPI_LINUX_FPGA_H
> +#define _UAPI_LINUX_FPGA_H
> +
> +#include <linux/ioctl.h>
> +#include <linux/types.h>
> +
> +#define FPGA_IOCTL_LOAD_DMA_BUF	_IOW('J', 1, __s32)

[Severity: High]
Since this IOCTL only takes a file descriptor (__s32), how does userspace
supply the exact payload size of the firmware?

In fpga_dmabuf_load(), the info struct is zero-allocated, leaving
info->data_size as 0. When fpga_mgr_buf_load_sg() evaluates the scatterlist,
if data_size is 0, it loops over the entire mapped capacity of the sg_table.

Because dma-bufs are typically page-aligned, will this result in writing
padding bytes at the end of the buffer directly into the FPGA configuration
port, potentially corrupting the hardware state?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1