Re: [PATCH v4 3/6] PCI: endpoint: Add API to delegate EPC DMA channels to the host

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but pre-existing API functions `pci_epc_get_aux_resources()` and `pci_epc_get_aux_resources_count()` unconditionally dereference `epc` before checking if it is an `ERR_PTR`.
--

--- Patch [3]: [PATCH v4 3/6] PCI: endpoint: Add API to delegate EPC DMA channels to the host ---
commit 1d374b51cba0f1ce466c2d806368e6604aa12539
Author: Koichiro Den <den@valinux.co.jp>

PCI: endpoint: Add API to delegate EPC DMA channels to the host

Some endpoint functions expose an EPC-integrated DMA controller to the
host. The endpoint function should not need to know the backend-specific
mechanism used to reserve a channel locally and hand its programming
interface to the host.

> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index 831b40458dcd8..9c908051aa235 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c

[ ... ]

> @@ -236,6 +243,101 @@ int pci_epc_get_aux_resources(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
>  }
>  EXPORT_SYMBOL_GPL(pci_epc_get_aux_resources);
>  
> +/**
> + * pci_epc_delegate_dma_chan() - delegate an EPC-owned DMA channel to the host
> + * @epc: EPC device
> + * @func_no: function number
> + * @vfunc_no: virtual function number
> + * @dir: DMA channel direction relative to the endpoint
> + * @hw_ch: hardware channel number
> + * @chan: output delegated-channel handle
> + *
> + * Some EPC backends integrate DMA channels that can be exposed to the host.
> + * This helper asks the backend to reserve the specified channel locally and
> + * place it in a state where the host driver may program it through the exposed
> + * register window.
> + *
> + * Return: 0 on success, -EOPNOTSUPP if the backend does not support DMA channel
> + * delegation, or another -errno on failure.
> + */
> +int pci_epc_delegate_dma_chan(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> +			      enum pci_epc_aux_dma_dir dir, u16 hw_ch,
> +			      struct pci_epc_dma_chan **chan)
> +{
> +	struct pci_epc_dma_chan *epc_chan;
> +	void *data = NULL;
> +	int ret;
> +
> +	if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> +		return -EINVAL;

[Severity: High]
This is a pre-existing issue, but while you correctly call
pci_epc_function_is_valid() here first to avoid dereferencing an error
pointer, could the pre-existing pci_epc_get_aux_resources() and
pci_epc_get_aux_resources_count() functions be crashing for the same
reason?

Looking at pci_epc_get_aux_resources() in drivers/pci/endpoint/pci-epc-core.c:

	if (!epc || !epc->ops)
		return -EINVAL;

	if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
		return -EINVAL;

If epc is an ERR_PTR, the !epc NULL check passes, and it crashes when
dereferencing epc->ops before reaching pci_epc_function_is_valid().

Does it make sense to update these sibling functions as well to ensure they
safely handle an ERR_PTR?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260710082156.2395844-1-den@valinux.co.jp?part=3