|WARNING| [2/2] net/iavf: fix leak of queue to traffic class mapping data
dpdklab at iol.unh.edu
dpdklab at iol.unh.edu
Fri Jul 3 11:05:24 CEST 2026
Test-Label: ai-code-review
Test-Status: WARNING
https://dpdk.org/patch/166501
_AI Code Review_
=== Patch Review: series.patch (via Claude) ===
Review date: 2026-07-03
# DPDK Patch Review
## PATCH 1/2: net/iavf: fix local memory leaks in TM hierarchy commit
### Errors
None.
### Warnings
**Queue-related buffer allocation using `calloc()` instead of `rte_zmalloc_socket()`**
The `q_tc_mapping` and `q_bw` structures are queue-related configuration buffers that will be sent to the device and potentially accessed by secondary processes. Using standard `calloc()` instead of `rte_zmalloc_socket()` breaks secondary process access (memory not in shared hugepages) and loses NUMA locality benefits.
```c
/* Current code after patch */
q_tc_mapping = calloc(1, size);
q_bw = calloc(1, size_q);
/* Should be */
q_tc_mapping = rte_zmalloc_socket("q_tc", size, 0, socket_id);
q_bw = rte_zmalloc_socket("q_bw", size_q, 0, socket_id);
```
The commit message states these are "temporary variables" that don't need hugepage memory, but they are passed to `iavf_set_q_tc_map()` and `iavf_set_q_bw()` which likely communicate with the device. Queue configuration structures should remain in hugepage memory for secondary process visibility and NUMA affinity.
### Info
The memory leak fix itself is correct - the patch properly frees `q_tc_mapping` and `q_bw` on all exit paths (success and error). The addition of `NULL` initialization is good defensive programming. However, the switch from `rte_zmalloc()` to `calloc()` may be incorrect depending on how these structures are used downstream.
---
## PATCH 2/2: net/iavf: fix leak of queue to traffic class mapping data
### Errors
None.
### Warnings
**Queue-related data structure using `calloc()` instead of `rte_zmalloc_socket()`**
Similar to Patch 1/2, the `qtc_map` structure stores queue-to-TC mapping configuration (`vf->qtc_map`) that persists across device operations and is likely accessed during packet transmission path decisions. This should be allocated from hugepage memory for secondary process visibility and NUMA locality.
```c
/* Current code after patch */
qtc_map = calloc(q_tc_mapping->num_tc, sizeof(struct iavf_qtc_map));
/* Should be */
qtc_map = rte_zmalloc_socket("qtc_map",
q_tc_mapping->num_tc * sizeof(struct iavf_qtc_map),
0, socket_id);
```
The commit message states the data is "unnecessarily allocated from hugepage memory," but this appears to be persistent device configuration state stored in `vf->qtc_map` and used for queue validation (see the Fixes tag referencing packet checking with "correct UP and queue"). Such data should remain in hugepages.
### Info
The leak fix logic is correct:
- Frees old mapping when replaced with new one (`old_qtc_map`)
- Frees mapping in `iavf_tm_conf_uninit()` and `iavf_uninit_vf()`
- Frees on error path when new allocation fails
The error path cleanup at `fail_clear` now properly frees `qtc_map` if allocation succeeded but a later operation failed.
---
## General Comments
Both patches correctly identify and fix memory leaks. The cleanup logic on all exit paths (success, normal error, `fail_clear` label) is sound. The addition of `NULL` checks and initialization improves safety.
However, both patches convert queue-related configuration structures from `rte_zmalloc()` to `calloc()`, which may break secondary process support and lose NUMA locality. The commit messages claim these structures don't need hugepage memory, but:
1. They configure device queues (not just control-plane metadata)
2. At least one (`qtc_map`) is persistent device state stored in `vf->` and used for packet classification
3. DPDK's architecture expects device configuration in shared hugepages
Unless the author can confirm these structures are purely transient and never accessed by secondary processes or the data plane, the switch to `calloc()` should be reconsidered. The leak fixes themselves are correct and valuable regardless of the allocation mechanism.
More information about the test-report
mailing list