[Intel-wired-lan] [PATCH net] idpf: Fix incorrect NULL check in completion descriptor release

[Intel-wired-lan] [PATCH net] idpf: Fix incorrect NULL check in completion descriptor release

[Alok Tiwari]

idpf_compl_queue uses a union for comp, comp_4b, and desc_ring.
The release path should check complq->desc_ring to determine whether the
DMA descriptor ring was allocated. The existing check against
complq->comp is incorrect, as only desc_ring reliably reflects the
allocation status.

Fixes: cfe5efec9177 ("idpf: add 4-byte completion descriptor definition")
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
---
 drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
index 828f7c444d30..1e7ae6f969ac 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
@@ -134,7 +134,7 @@ static void idpf_compl_desc_rel(struct idpf_compl_queue *complq)
 {
 	idpf_xsk_clear_queue(complq, VIRTCHNL2_QUEUE_TYPE_TX_COMPLETION);
 
-	if (!complq->comp)
+	if (!complq->desc_ring)
 		return;
 
 	dma_free_coherent(complq->netdev->dev.parent, complq->size,
-- 
2.50.1

Re: [Intel-wired-lan] [PATCH net] idpf: Fix incorrect NULL check in completion descriptor release

[Alexander Lobakin]

From: Alok Tiwari <alok.a.tiwari@oracle.com>
Date: Mon, 17 Nov 2025 02:22:25 -0800

> idpf_compl_queue uses a union for comp, comp_4b, and desc_ring.
> The release path should check complq->desc_ring to determine whether the
> DMA descriptor ring was allocated. The existing check against
> complq->comp is incorrect, as only desc_ring reliably reflects the
> allocation status.

How can it be "incorrect" if these 3 are in the same union and have the
same size of 1 pointer? Any of them reflects the allocation status.

While your change improves readability, it doesn't fixes anything at
all. You can compare the object code to see there's no difference
before/after.

C unions are not the same as C++ unions, but even if the kernel had
`-fstrict-aliasing` enabled (and it's always disabled), the result would
be same. And C unions definitely don't work like std::variant.

So this could only go to -next as a cosmetic change if you really want this.

> 
> Fixes: cfe5efec9177 ("idpf: add 4-byte completion descriptor definition")
> Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
> ---
>  drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> index 828f7c444d30..1e7ae6f969ac 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> @@ -134,7 +134,7 @@ static void idpf_compl_desc_rel(struct idpf_compl_queue *complq)
>  {
>  	idpf_xsk_clear_queue(complq, VIRTCHNL2_QUEUE_TYPE_TX_COMPLETION);
>  
> -	if (!complq->comp)
> +	if (!complq->desc_ring)
>  		return;
>  
>  	dma_free_coherent(complq->netdev->dev.parent, complq->size,

Thanks,
Olek

Re: [Intel-wired-lan] [External] : Re: [PATCH net] idpf: Fix incorrect NULL check in completion descriptor release

[ALOK TIWARI]

On 11/17/2025 4:00 PM, Alexander Lobakin wrote:
>> idpf_compl_queue uses a union for comp, comp_4b, and desc_ring.
>> The release path should check complq->desc_ring to determine whether the
>> DMA descriptor ring was allocated. The existing check against
>> complq->comp is incorrect, as only desc_ring reliably reflects the
>> allocation status.
> How can it be "incorrect" if these 3 are in the same union and have the
> same size of 1 pointer? Any of them reflects the allocation status.
> 
> While your change improves readability, it doesn't fixes anything at
> all. You can compare the object code to see there's no difference
> before/after.
> 
> C unions are not the same as C++ unions, but even if the kernel had
> `-fstrict-aliasing` enabled (and it's always disabled), the result would
> be same. And C unions definitely don't work like std::variant.
> 
> So this could only go to -next as a cosmetic change if you really want this.
> 

Thanks, Alex.
Agreed the check is functionally identical. I’ll mark it for net-next.


Thanks,
Alok