Re: [PATCH] nvmet: pci-epf: put CQ ref on create_cq mapping failure
Damien Le Moal <[email protected]> Wed, 5 Aug 2026 07:28:09 +0900
| Newsgroups | org.infradead.lists.linux-nvme,org.kernel.vger.linux-kernel,org.kernel.vger.stable |
|---|---|
| Organization | Western Digital Research |
| Message-ID | <[email protected]> |
On 8/5/26 06:36, Yifei Gao wrote:
> nvmet_pci_epf_create_cq() calls nvmet_cq_create(), which takes a
> reference on the controller and installs the completion queue. If the
> subsequent PCI address-space mapping fails or returns a too-small partial
> mapping, the function jumps to err_internal / err_unmap_queue without
> calling nvmet_cq_put(). The matching put in nvmet_pci_epf_delete_cq() is
> gated on NVMET_PCI_EPF_Q_LIVE, which is only set after the mapping
> succeeds, so teardown never releases these references. A remote PCI host
> that drives Create IO CQ commands with a failing PRP1/pci_addr therefore
> leaks the CQ and a controller reference on each attempt.
>
> Drop the CQ reference on the mapping-failure paths. The err_internal and
> err_unmap_queue labels are only reachable after nvmet_cq_create() has
> succeeded, so this pairs the create/put correctly.
>
> Fixes: 0faa0fe6f90e ("nvmet: New NVMe PCI endpoint function target driver")
> Cc: [email protected]
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Yifei Gao <[email protected]>
Looks OK.
Reviewed-by: Damien Le Moal <[email protected]>
Note: it would be nice if could explicitly mention if you actually tested this
or if this is just an AI generated fix.
--
Damien Le Moal
Western Digital Research