On Sun, Jan 4, 2026 at 11:43 PM Loktionov, Aleksandr
<[email protected]> wrote:
>
>
>
>
>
> From: Li Li <[email protected]>
> Sent: Monday, January 5, 2026 8:39 AM
> To: Loktionov, Aleksandr <[email protected]>
> Cc: Nguyen, Anthony L <[email protected]>; Kitszel, Przemyslaw
> <[email protected]>; David S. Miller <[email protected]>; Jakub
> Kicinski <[email protected]>; Eric Dumazet <[email protected]>;
> [email protected]; [email protected];
> [email protected]; David Decotigny <[email protected]>; Singhai,
> Anjali <[email protected]>; Samudrala, Sridhar
> <[email protected]>; Brian Vazquez <[email protected]>; Tantilov,
> Emil S <[email protected]>
> Subject: Re: [Intel-wired-lan] [PATCH v2] idpf: increment completion queue
> next_to_clean in sw marker wait routine
>
>
>
>
>
>
>
> On Sun, Jan 4, 2026 at 11:19 PM Loktionov, Aleksandr
> <[email protected]> wrote:
>
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <[email protected]> On Behalf
> > Of Li Li via Intel-wired-lan
> > Sent: Monday, January 5, 2026 7:47 AM
> > To: Nguyen, Anthony L <[email protected]>; Kitszel,
> > Przemyslaw <[email protected]>; David S. Miller
> > <[email protected]>; Jakub Kicinski <[email protected]>; Eric Dumazet
> > <[email protected]>; [email protected]
> > Cc: [email protected]; [email protected]; David
> > Decotigny <[email protected]>; Singhai, Anjali
> > <[email protected]>; Samudrala, Sridhar
> > <[email protected]>; Brian Vazquez <[email protected]>;
> > Tantilov, Emil S <[email protected]>; Li Li
> > <[email protected]>
> > Subject: [Intel-wired-lan] [PATCH v2] idpf: increment completion queue
> > next_to_clean in sw marker wait routine
> >
> > Currently, in idpf_wait_for_sw_marker_completion(), when an
> > IDPF_TXD_COMPLT_SW_MARKER packet is found, the routine breaks out of
> > the for loop and does not increment the next_to_clean counter. This
> > causes the subsequent NAPI polls to run into the same
> > IDPF_TXD_COMPLT_SW_MARKER packet again and print out the following:
> >
> > [ 23.261341] idpf 0000:05:00.0 eth1: Unknown TX completion type:
> > 5
> >
> > Instead, we should increment next_to_clean regardless when an
> > IDPF_TXD_COMPLT_SW_MARKER packet is found.
> >
> > Tested: with the patch applied, we do not see the errors above from
> > NAPI polls anymore.
> >
> > Signed-off-by: Li Li <[email protected]>
> > ---
> > Changes in v2:
> > - Initialize idpf_tx_queue *target to NULL to suppress the "'target'
> > uninitialized when 'if' statement is true warning".
> >
> > drivers/net/ethernet/intel/idpf/idpf_txrx.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> > b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> > index 69bab7187e541..452d0a9e83a4f 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> > +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> > @@ -2326,7 +2326,7 @@ void idpf_wait_for_sw_marker_completion(const
> > struct idpf_tx_queue *txq)
> >
> > do {
> > struct idpf_splitq_4b_tx_compl_desc *tx_desc;
> > - struct idpf_tx_queue *target;
> > + struct idpf_tx_queue *target = NULL;
> Linux kernel is against premature initialization just to silence a compiler.
> The target variable is dereferenced at idpf_queue_clear(SW_MARKER, target))
> but can remain uninitialized if execution jumps to the next: label via a goto
> before target is assigned.
> Isn't it?
>
> That is correct. When the following if statement (line 2341-2343) evaluates
> to true:
>
>
>
> if (FIELD_GET(IDPF_TXD_COMPLQ_COMPL_TYPE_M, ctype_gen) !=
> IDPF_TXD_COMPLT_SW_MARKER)
> goto next;
>
>
>
> Then the initialization at line 2346:
>
>
>
> target = complq->txq_grp->txqs[id];
>
>
>
> would be skipped, making "target" uninitialized.
>
>
>
> Therefore, in this patch, I need to initialize "target" to NULL.
>
>
>
> The ‘NULL’ target variable can be dereferenced at idpf_queue_clear(SW_MARKER,
> target)), isn’t it?
That would not be possible, because right before
"idpf_queue_clear(SW_MARKER, target))", "target"
is initialized to "complq->txq_grp->txqs[id]":
if (FIELD_GET(IDPF_TXD_COMPLQ_COMPL_TYPE_M, ctype_gen) !=
IDPF_TXD_COMPLT_SW_MARKER)
goto next;
id = FIELD_GET(IDPF_TXD_COMPLQ_QID_M, ctype_gen);
target = complq->txq_grp->txqs[id];
idpf_queue_clear(SW_MARKER, target);
"target" only remains uninitialized if the if statement above
evaluates to true and skips the initialization.
>
>
>
>
>
>
> > u32 ctype_gen, id;
> >
> > tx_desc = flow ? &complq->comp[ntc].common :
> > @@ -2346,14 +2346,14 @@ void idpf_wait_for_sw_marker_completion(const
> > struct idpf_tx_queue *txq)
> > target = complq->txq_grp->txqs[id];
> >
> > idpf_queue_clear(SW_MARKER, target);
> > - if (target == txq)
> > - break;
> >
> > next:
> > if (unlikely(++ntc == complq->desc_count)) {
> > ntc = 0;
> > gen_flag = !gen_flag;
> > }
> > + if (target == txq)
> Are tou sure that incremented ntc value is ever written back to
> complq->next_to_clean?
>
>
>
> Yes, the value of "ntc" is written back to "complq->next_to_clean" at the end
> of the function
>
> (at line 2360):
>
>
>
> complq->next_to_clean = ntc;
>
> Thank you, I don’t see it from the patch.
>
>
>
>
> > + break;
> > } while (time_before(jiffies, timeout));
> >
> > idpf_queue_assign(GEN_CHK, complq, gen_flag);
> > --
> > 2.52.0.351.gbe84eed79e-goog
