On Fri, 13 Feb 2026 10:26:33 +0000 Anatoly Burakov <[email protected]> wrote:
> Currently, when enabling, disabling, or switching queues, we are using > rte_malloc followed by an immediate rte_free. This is not needed as these > structures are not being stored anywhere, so replace them with stack > allocation or malloc/free where appropriate. > > Signed-off-by: Anatoly Burakov <[email protected]> AI caught something here. Patch 22/27 — net/iavf: avoid rte malloc in queue operations Error (Correctness — Uninitialized stack memory) In iavf_switch_queue_lv(), the stack-allocated queue_req is not zero-initialized:  c } queue_req; /* <-- no "= {0}" */ The original code used rte_zmalloc which zeroes the buffer. The other two functions in this same patch (iavf_enable_queues_lv and iavf_disable_queues_lv) correctly use = {0}, but iavf_switch_queue_lv does not. The structure is then sent as a virtchnl message via args.in_args, meaning uninitialized stack bytes will be transmitted to the PF driver. While individual fields like num_chunks, vport_id, queue_type, start_queue_id, and num_queues are set explicitly, padding bytes and any other fields within the struct will contain garbage. Additionally, this function previously allocated only sizeof(struct virtchnl_del_ena_dis_queues) (which includes exactly 1 chunk), but the new stack struct includes IAVF_RXTX_QUEUE_CHUNKS_NUM - 1 additional chunks. Since num_chunks is set to 1, the extra space is harmless — but passing sizeof(queue_req) as in_args_size now sends a larger buffer than before. Compare with the enable/disable functions which also have the extra chunks but actually use IAVF_RXTX_QUEUE_CHUNKS_NUM chunks. The size change is likely benign but worth noting. Fix: Add = {0} to the declaration, matching the pattern in the sibling functions in the same patch:  c } queue_req = {0};
