|SUCCESS| [v1,1/1] net/iavf: fix large VF IRQ mapping

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/163686

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-05-06

git sha: c50ef6c3d4ecaa7902d325d5e8a7fd4c92c8eeb6
Author: Anatoly Burakov <anatoly.burakov at intel.com>
Subject: net/iavf: fix large VF IRQ mapping

This patch fixes a buffer size calculation issue in the iavf virtual channel
code where the size of the virtchnl_queue_vector_maps structure was incorrectly
computed.

> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c b/drivers/net/intel/iavf/iavf_vchnl.c
> index c2f340db81..dd09b0fa61 100644
> --- a/drivers/net/intel/iavf/iavf_vchnl.c
> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
> @@ -1528,7 +1528,7 @@ iavf_config_irq_map_lv_chunk(struct iavf_adapter *adapter,
>  
>  	/* for some reason PF side checks for buffer being too big, so adjust it down */
>  	buf_len = sizeof(struct virtchnl_queue_vector_maps) +
> -		  sizeof(struct virtchnl_queue_vector) * chunk_sz;
> +		  sizeof(struct virtchnl_queue_vector) * (chunk_sz - 1);

Does this calculation correctly handle the case when chunk_sz is zero?
If chunk_sz is initialized to zero at some call site (or through any error
path leading here), the expression (chunk_sz - 1) would underflow and
create an excessively large buffer size calculation.

Does the function iavf_config_irq_map_lv_chunk() validate chunk_sz before
using it in this computation?

The comment mentions "for some reason PF side checks for buffer being too
big", which suggests this is working around a constraint rather than
following a clear specification. Has this off-by-one adjustment been
verified against the actual virtchnl_queue_vector_maps structure definition
to confirm that it indeed contains one queue vector element already?