Re: [Intel-wired-lan] [PATCH v2] idpf: increment completion queue next_to_clean in sw marker wait routine
> -Original Message- > From: Li Li > Sent: Monday, January 5, 2026 8:49 AM > To: Loktionov, Aleksandr > Cc: Nguyen, Anthony L ; Kitszel, > Przemyslaw ; David S. Miller > ; Jakub Kicinski ; Eric Dumazet > ; [email protected]; > [email protected]; [email protected]; David Decotigny > ; Singhai, Anjali ; > Samudrala, Sridhar ; Brian Vazquez > ; Tantilov, Emil S > 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:43 PM Loktionov, Aleksandr > wrote: > > > > > > > > > > > > From: Li Li > > Sent: Monday, January 5, 2026 8:39 AM > > To: Loktionov, Aleksandr > > Cc: Nguyen, Anthony L ; Kitszel, > > Przemyslaw ; David S. Miller > > ; Jakub Kicinski ; Eric > Dumazet > > ; [email protected]; > > [email protected]; [email protected]; David > Decotigny > > ; Singhai, Anjali ; > > Samudrala, Sridhar ; Brian Vazquez > > ; Tantilov, Emil S > > 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 > wrote: > > > > > > > > > -Original Message- > > > From: Intel-wired-lan On > Behalf > > > Of Li Li via Intel-wired-lan > > > Sent: Monday, January 5, 2026 7:47 AM > > > To: Nguyen, Anthony L ; Kitszel, > > > Przemyslaw ; David S. Miller > > > ; Jakub Kicinski ; Eric > > > Dumazet ; [email protected] > > > Cc: [email protected]; [email protected]; David > > > Decotigny ; Singhai, Anjali > > > ; Samudrala, Sridhar > > > ; Brian Vazquez ; > > > Tantilov, Emil S ; Li Li > > > > > > 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 :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 > > > --- > > > 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];
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:43 PM Loktionov, Aleksandr wrote: > > > > > > From: Li Li > Sent: Monday, January 5, 2026 8:39 AM > To: Loktionov, Aleksandr > Cc: Nguyen, Anthony L ; Kitszel, Przemyslaw > ; David S. Miller ; Jakub > Kicinski ; Eric Dumazet ; > [email protected]; [email protected]; > [email protected]; David Decotigny ; Singhai, > Anjali ; Samudrala, Sridhar > ; Brian Vazquez ; Tantilov, > Emil S > 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 > wrote: > > > > > -Original Message- > > From: Intel-wired-lan On Behalf > > Of Li Li via Intel-wired-lan > > Sent: Monday, January 5, 2026 7:47 AM > > To: Nguyen, Anthony L ; Kitszel, > > Przemyslaw ; David S. Miller > > ; Jakub Kicinski ; Eric Dumazet > > ; [email protected] > > Cc: [email protected]; [email protected]; David > > Decotigny ; Singhai, Anjali > > ; Samudrala, Sridhar > > ; Brian Vazquez ; > > Tantilov, Emil S ; Li Li > > > > 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 :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 > > --- > > 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) > >
Re: [Intel-wired-lan] [PATCH v2] idpf: increment completion queue next_to_clean in sw marker wait routine
From: Li Li Sent: Monday, January 5, 2026 8:39 AM To: Loktionov, Aleksandr Cc: Nguyen, Anthony L ; Kitszel, Przemyslaw ; David S. Miller ; Jakub Kicinski ; Eric Dumazet ; [email protected]; [email protected]; [email protected]; David Decotigny ; Singhai, Anjali ; Samudrala, Sridhar ; Brian Vazquez ; Tantilov, Emil S 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 mailto:[email protected]>> wrote: > -Original Message- > From: Intel-wired-lan > mailto:[email protected]>> > On Behalf > Of Li Li via Intel-wired-lan > Sent: Monday, January 5, 2026 7:47 AM > To: Nguyen, Anthony L > mailto:[email protected]>>; Kitszel, > Przemyslaw > mailto:[email protected]>>; David S. > Miller > mailto:[email protected]>>; Jakub Kicinski > mailto:[email protected]>>; Eric Dumazet > mailto:[email protected]>>; > [email protected]<mailto:[email protected]> > Cc: [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; David > Decotigny mailto:[email protected]>>; Singhai, Anjali > mailto:[email protected]>>; Samudrala, > Sridhar > mailto:[email protected]>>; Brian > Vazquez mailto:[email protected]>>; > Tantilov, Emil S > mailto:[email protected]>>; Li Li > mailto:[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 :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 mailto:[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? > 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
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 On Behalf > > Of Li Li via Intel-wired-lan > > Sent: Monday, January 5, 2026 7:47 AM > > To: Nguyen, Anthony L ; Kitszel, > > Przemyslaw ; David S. Miller > > ; Jakub Kicinski ; Eric Dumazet > > ; [email protected] > > Cc: [email protected]; [email protected]; David > > Decotigny ; Singhai, Anjali > > ; Samudrala, Sridhar > > ; Brian Vazquez ; > > Tantilov, Emil S ; Li Li > > > > 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 :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 > > --- > > 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. > > 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; > > > + break; > > } while (time_before(jiffies, timeout)); > > > > idpf_queue_assign(GEN_CHK, complq, gen_flag); > > -- > > 2.52.0.351.gbe84eed79e-goog > >
Re: [Intel-wired-lan] [PATCH v2] idpf: increment completion queue next_to_clean in sw marker wait routine
> -Original Message- > From: Intel-wired-lan On Behalf > Of Li Li via Intel-wired-lan > Sent: Monday, January 5, 2026 7:47 AM > To: Nguyen, Anthony L ; Kitszel, > Przemyslaw ; David S. Miller > ; Jakub Kicinski ; Eric Dumazet > ; [email protected] > Cc: [email protected]; [email protected]; David > Decotigny ; Singhai, Anjali > ; Samudrala, Sridhar > ; Brian Vazquez ; > Tantilov, Emil S ; Li Li > > 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 :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 > --- > 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? > 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? > + break; > } while (time_before(jiffies, timeout)); > > idpf_queue_assign(GEN_CHK, complq, gen_flag); > -- > 2.52.0.351.gbe84eed79e-goog
