This is an AI-generated review of your patch. The human sending this email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html --- idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL This patch adds a NULL check for rx_qgrp->splitq.bufq_sets to prevent kernel panic when idpf_rxq_group_alloc() fails during initialization and the error path calls idpf_rxq_sw_queue_rel(). The panic was occurring during device opening when adding to a bonding interface. > diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > index 761a77510467..59aafadae3d0 100644 > --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > @@ -1341,6 +1341,9 @@ static void idpf_txq_group_rel(struct idpf_q_vec_rsrc > *rsrc) > */ > static void idpf_rxq_sw_queue_rel(struct idpf_rxq_group *rx_qgrp) > { > + if (!rx_qgrp->splitq.bufq_sets) > + return; > + > for (unsigned int i = 0; i < rx_qgrp->splitq.num_bufq_sets; i++) { > struct idpf_bufq_set *bufq_set = &rx_qgrp->splitq.bufq_sets[i]; > > for (unsigned int j = 0; j < bufq_set->num_refillqs; j++) { > kfree(bufq_set->refillqs[j].ring); > bufq_set->refillqs[j].ring = NULL; ^^^^^^ This patch adds a NULL check for bufq_sets, but does the same issue exist for refillqs? Looking at idpf_rxq_group_alloc() in the same file, it first sets bufq_set->num_refillqs to a non-zero value, then attempts to allocate refillqs: idpf_rxq_group_alloc() { ... bufq_set->num_refillqs = num_rxq; bufq_set->refillqs = kcalloc(bufq_set->num_refillqs, sizeof(struct idpf_sw_queue), GFP_KERNEL); if (!bufq_set->refillqs) { err = -ENOMEM; goto err_alloc; } ... } If this allocation fails, bufq_set->refillqs is NULL but bufq_set->num_refillqs is non-zero. The error path calls idpf_rxq_sw_queue_rel() which now passes the bufq_sets check but then dereferences bufq_set->refillqs[j].ring in the inner loop. The inner loop condition (j < bufq_set->num_refillqs) would be true, causing the same NULL pointer dereference the patch is meant to prevent. Would this need a similar check before the inner loop, similar to the bufq_sets check added in this patch?
