* [PATCH 0/2] idpf: skip NULL pointers during deallocation. @ 2026-01-12 23:09 Li Li 2026-01-12 23:09 ` [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL Li Li 2026-01-12 23:09 ` [PATCH 2/2] idpf: skip deallocating txq group's txqs " Li Li 0 siblings, 2 replies; 10+ messages in thread From: Li Li @ 2026-01-12 23:09 UTC (permalink / raw) To: Tony Nguyen, Przemek Kitszel, David S. Miller, Jakub Kicinski, Eric Dumazet, intel-wired-lan Cc: netdev, linux-kernel, David Decotigny, Anjali Singhai, Sridhar Samudrala, Brian Vazquez, Li Li, emil.s.tantilov In idpf txq and rxq error paths, some pointers are not allocated in the first place. In the corresponding deallocation logic, we should not deallocate them to prevent kernel panics. Li Li (2): idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL. idpf: skip deallocating txq group's txqs if it is NULL. drivers/net/ethernet/intel/idpf/idpf_txrx.c | 5 +++++ 1 file changed, 5 insertions(+) -- 2.52.0.457.g6b5491de43-goog ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL. 2026-01-12 23:09 [PATCH 0/2] idpf: skip NULL pointers during deallocation Li Li @ 2026-01-12 23:09 ` Li Li 2026-01-13 6:31 ` [Intel-wired-lan] " Paul Menzel 2026-01-13 7:34 ` Loktionov, Aleksandr 2026-01-12 23:09 ` [PATCH 2/2] idpf: skip deallocating txq group's txqs " Li Li 1 sibling, 2 replies; 10+ messages in thread From: Li Li @ 2026-01-12 23:09 UTC (permalink / raw) To: Tony Nguyen, Przemek Kitszel, David S. Miller, Jakub Kicinski, Eric Dumazet, intel-wired-lan Cc: netdev, linux-kernel, David Decotigny, Anjali Singhai, Sridhar Samudrala, Brian Vazquez, Li Li, emil.s.tantilov In idpf_rxq_group_alloc(), if rx_qgrp->splitq.bufq_sets failed to get allocated: rx_qgrp->splitq.bufq_sets = kcalloc(vport->num_bufqs_per_qgrp, sizeof(struct idpf_bufq_set), GFP_KERNEL); if (!rx_qgrp->splitq.bufq_sets) { err = -ENOMEM; goto err_alloc; } idpf_rxq_group_rel() would attempt to deallocate it in idpf_rxq_sw_queue_rel(), causing a kernel panic: ``` [ 7.967242] early-network-sshd-n-rexd[3148]: knetbase: Info: [ 8.127804] BUG: kernel NULL pointer dereference, address: 00000000000000c0 ... [ 8.129779] RIP: 0010:idpf_rxq_group_rel+0x101/0x170 ... [ 8.133854] Call Trace: [ 8.133980] <TASK> [ 8.134092] idpf_vport_queues_alloc+0x286/0x500 [ 8.134313] idpf_vport_open+0x4d/0x3f0 [ 8.134498] idpf_open+0x71/0xb0 [ 8.134668] __dev_open+0x142/0x260 [ 8.134840] netif_open+0x2f/0xe0 [ 8.135004] dev_open+0x3d/0x70 [ 8.135166] bond_enslave+0x5ed/0xf50 [ 8.135345] ? nla_put_ifalias+0x3d/0x90 [ 8.135533] ? kvfree_call_rcu+0xb5/0x3b0 [ 8.135725] ? kvfree_call_rcu+0xb5/0x3b0 [ 8.135916] do_set_master+0x114/0x160 [ 8.136098] do_setlink+0x412/0xfb0 [ 8.136269] ? security_sock_rcv_skb+0x2a/0x50 [ 8.136509] ? sk_filter_trim_cap+0x7c/0x320 [ 8.136714] ? skb_queue_tail+0x20/0x50 [ 8.136899] ? __nla_validate_parse+0x92/0xe50 [ 8.137112] ? security_capable+0x35/0x60 [ 8.137304] rtnl_newlink+0x95c/0xa00 [ 8.137483] ? __rtnl_unlock+0x37/0x70 [ 8.137664] ? netdev_run_todo+0x63/0x530 [ 8.137855] ? allocate_slab+0x280/0x870 [ 8.138044] ? security_capable+0x35/0x60 [ 8.138235] rtnetlink_rcv_msg+0x2e6/0x340 [ 8.138431] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 8.138650] netlink_rcv_skb+0x16a/0x1a0 [ 8.138840] netlink_unicast+0x20a/0x320 [ 8.139028] netlink_sendmsg+0x304/0x3b0 [ 8.139217] __sock_sendmsg+0x89/0xb0 [ 8.139399] ____sys_sendmsg+0x167/0x1c0 [ 8.139588] ? ____sys_recvmsg+0xed/0x150 [ 8.139780] ___sys_sendmsg+0xdd/0x120 [ 8.139960] ? ___sys_recvmsg+0x124/0x1e0 [ 8.140152] ? rcutree_enqueue+0x1f/0xb0 [ 8.140341] ? rcutree_enqueue+0x1f/0xb0 [ 8.140528] ? call_rcu+0xde/0x2a0 [ 8.140695] ? evict+0x286/0x2d0 [ 8.140856] ? rcutree_enqueue+0x1f/0xb0 [ 8.141043] ? kmem_cache_free+0x2c/0x350 [ 8.141236] __x64_sys_sendmsg+0x72/0xc0 [ 8.141424] do_syscall_64+0x6f/0x890 [ 8.141603] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 8.141841] RIP: 0033:0x7f2799d21bd0 ... [ 8.149905] Kernel panic - not syncing: Fatal exception [ 8.175940] Kernel Offset: 0xf800000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 8.176425] Rebooting in 10 seconds.. ``` Tested: With this patch, the kernel panic no longer appears. Fixes: 95af467d9a4e ("idpf: configure resources for RX queues") Signed-off-by: Li Li <boolli@google.com> --- drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c index e7b131dba200c..b4dab4a8ee11b 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c @@ -1337,6 +1337,8 @@ static void idpf_txq_group_rel(struct idpf_vport *vport) static void idpf_rxq_sw_queue_rel(struct idpf_rxq_group *rx_qgrp) { int i, j; + if (!rx_qgrp->splitq.bufq_sets) + return; for (i = 0; i < rx_qgrp->vport->num_bufqs_per_qgrp; i++) { struct idpf_bufq_set *bufq_set = &rx_qgrp->splitq.bufq_sets[i]; -- 2.52.0.457.g6b5491de43-goog ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [Intel-wired-lan] [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL. 2026-01-12 23:09 ` [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL Li Li @ 2026-01-13 6:31 ` Paul Menzel 2026-01-15 20:07 ` Li Li 2026-01-13 7:34 ` Loktionov, Aleksandr 1 sibling, 1 reply; 10+ messages in thread From: Paul Menzel @ 2026-01-13 6:31 UTC (permalink / raw) To: Li Li Cc: Tony Nguyen, Przemek Kitszel, David S. Miller, Jakub Kicinski, Eric Dumazet, intel-wired-lan, netdev, linux-kernel, David Decotigny, Anjali Singhai, Sridhar Samudrala, Brian Vazquez, emil.s.tantilov Dear Li, Thank you for your patch. Am 13.01.26 um 00:09 schrieb Li Li via Intel-wired-lan: > In idpf_rxq_group_alloc(), if rx_qgrp->splitq.bufq_sets failed to get > allocated: > > rx_qgrp->splitq.bufq_sets = kcalloc(vport->num_bufqs_per_qgrp, > sizeof(struct idpf_bufq_set), > GFP_KERNEL); > if (!rx_qgrp->splitq.bufq_sets) { > err = -ENOMEM; > goto err_alloc; > } > > idpf_rxq_group_rel() would attempt to deallocate it in > idpf_rxq_sw_queue_rel(), causing a kernel panic: > > ``` > [ 7.967242] early-network-sshd-n-rexd[3148]: knetbase: Info: [ 8.127804] BUG: kernel NULL pointer dereference, address: 00000000000000c0 > ... > [ 8.129779] RIP: 0010:idpf_rxq_group_rel+0x101/0x170 > ... > [ 8.133854] Call Trace: > [ 8.133980] <TASK> > [ 8.134092] idpf_vport_queues_alloc+0x286/0x500 > [ 8.134313] idpf_vport_open+0x4d/0x3f0 > [ 8.134498] idpf_open+0x71/0xb0 > [ 8.134668] __dev_open+0x142/0x260 > [ 8.134840] netif_open+0x2f/0xe0 > [ 8.135004] dev_open+0x3d/0x70 > [ 8.135166] bond_enslave+0x5ed/0xf50 > [ 8.135345] ? nla_put_ifalias+0x3d/0x90 > [ 8.135533] ? kvfree_call_rcu+0xb5/0x3b0 > [ 8.135725] ? kvfree_call_rcu+0xb5/0x3b0 > [ 8.135916] do_set_master+0x114/0x160 > [ 8.136098] do_setlink+0x412/0xfb0 > [ 8.136269] ? security_sock_rcv_skb+0x2a/0x50 > [ 8.136509] ? sk_filter_trim_cap+0x7c/0x320 > [ 8.136714] ? skb_queue_tail+0x20/0x50 > [ 8.136899] ? __nla_validate_parse+0x92/0xe50 > [ 8.137112] ? security_capable+0x35/0x60 > [ 8.137304] rtnl_newlink+0x95c/0xa00 > [ 8.137483] ? __rtnl_unlock+0x37/0x70 > [ 8.137664] ? netdev_run_todo+0x63/0x530 > [ 8.137855] ? allocate_slab+0x280/0x870 > [ 8.138044] ? security_capable+0x35/0x60 > [ 8.138235] rtnetlink_rcv_msg+0x2e6/0x340 > [ 8.138431] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 > [ 8.138650] netlink_rcv_skb+0x16a/0x1a0 > [ 8.138840] netlink_unicast+0x20a/0x320 > [ 8.139028] netlink_sendmsg+0x304/0x3b0 > [ 8.139217] __sock_sendmsg+0x89/0xb0 > [ 8.139399] ____sys_sendmsg+0x167/0x1c0 > [ 8.139588] ? ____sys_recvmsg+0xed/0x150 > [ 8.139780] ___sys_sendmsg+0xdd/0x120 > [ 8.139960] ? ___sys_recvmsg+0x124/0x1e0 > [ 8.140152] ? rcutree_enqueue+0x1f/0xb0 > [ 8.140341] ? rcutree_enqueue+0x1f/0xb0 > [ 8.140528] ? call_rcu+0xde/0x2a0 > [ 8.140695] ? evict+0x286/0x2d0 > [ 8.140856] ? rcutree_enqueue+0x1f/0xb0 > [ 8.141043] ? kmem_cache_free+0x2c/0x350 > [ 8.141236] __x64_sys_sendmsg+0x72/0xc0 > [ 8.141424] do_syscall_64+0x6f/0x890 > [ 8.141603] entry_SYSCALL_64_after_hwframe+0x76/0x7e > [ 8.141841] RIP: 0033:0x7f2799d21bd0 > ... > [ 8.149905] Kernel panic - not syncing: Fatal exception > [ 8.175940] Kernel Offset: 0xf800000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) > [ 8.176425] Rebooting in 10 seconds.. > ``` > > Tested: With this patch, the kernel panic no longer appears. Is it easy to reproduce? > Fixes: 95af467d9a4e ("idpf: configure resources for RX queues") > (Just for the future, a blank in the “tag section” is uncommon.) > Signed-off-by: Li Li <boolli@google.com> > --- > drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > index e7b131dba200c..b4dab4a8ee11b 100644 > --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > @@ -1337,6 +1337,8 @@ static void idpf_txq_group_rel(struct idpf_vport *vport) > static void idpf_rxq_sw_queue_rel(struct idpf_rxq_group *rx_qgrp) > { > int i, j; > + if (!rx_qgrp->splitq.bufq_sets) > + return; > > for (i = 0; i < rx_qgrp->vport->num_bufqs_per_qgrp; i++) { > struct idpf_bufq_set *bufq_set = &rx_qgrp->splitq.bufq_sets[i]; Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Kind regards, Paul ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [Intel-wired-lan] [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL. 2026-01-13 6:31 ` [Intel-wired-lan] " Paul Menzel @ 2026-01-15 20:07 ` Li Li 0 siblings, 0 replies; 10+ messages in thread From: Li Li @ 2026-01-15 20:07 UTC (permalink / raw) To: Paul Menzel Cc: Tony Nguyen, Przemek Kitszel, David S. Miller, Jakub Kicinski, Eric Dumazet, intel-wired-lan, netdev, linux-kernel, David Decotigny, Anjali Singhai, Sridhar Samudrala, Brian Vazquez, emil.s.tantilov On Mon, Jan 12, 2026 at 10:31 PM Paul Menzel <pmenzel@molgen.mpg.de> wrote: > > Dear Li, > > > Thank you for your patch. > > Am 13.01.26 um 00:09 schrieb Li Li via Intel-wired-lan: > > In idpf_rxq_group_alloc(), if rx_qgrp->splitq.bufq_sets failed to get > > allocated: > > > > rx_qgrp->splitq.bufq_sets = kcalloc(vport->num_bufqs_per_qgrp, > > sizeof(struct idpf_bufq_set), > > GFP_KERNEL); > > if (!rx_qgrp->splitq.bufq_sets) { > > err = -ENOMEM; > > goto err_alloc; > > } > > > > idpf_rxq_group_rel() would attempt to deallocate it in > > idpf_rxq_sw_queue_rel(), causing a kernel panic: > > > > ``` > > [ 7.967242] early-network-sshd-n-rexd[3148]: knetbase: Info: [ 8.127804] BUG: kernel NULL pointer dereference, address: 00000000000000c0 > > ... > > [ 8.129779] RIP: 0010:idpf_rxq_group_rel+0x101/0x170 > > ... > > [ 8.133854] Call Trace: > > [ 8.133980] <TASK> > > [ 8.134092] idpf_vport_queues_alloc+0x286/0x500 > > [ 8.134313] idpf_vport_open+0x4d/0x3f0 > > [ 8.134498] idpf_open+0x71/0xb0 > > [ 8.134668] __dev_open+0x142/0x260 > > [ 8.134840] netif_open+0x2f/0xe0 > > [ 8.135004] dev_open+0x3d/0x70 > > [ 8.135166] bond_enslave+0x5ed/0xf50 > > [ 8.135345] ? nla_put_ifalias+0x3d/0x90 > > [ 8.135533] ? kvfree_call_rcu+0xb5/0x3b0 > > [ 8.135725] ? kvfree_call_rcu+0xb5/0x3b0 > > [ 8.135916] do_set_master+0x114/0x160 > > [ 8.136098] do_setlink+0x412/0xfb0 > > [ 8.136269] ? security_sock_rcv_skb+0x2a/0x50 > > [ 8.136509] ? sk_filter_trim_cap+0x7c/0x320 > > [ 8.136714] ? skb_queue_tail+0x20/0x50 > > [ 8.136899] ? __nla_validate_parse+0x92/0xe50 > > [ 8.137112] ? security_capable+0x35/0x60 > > [ 8.137304] rtnl_newlink+0x95c/0xa00 > > [ 8.137483] ? __rtnl_unlock+0x37/0x70 > > [ 8.137664] ? netdev_run_todo+0x63/0x530 > > [ 8.137855] ? allocate_slab+0x280/0x870 > > [ 8.138044] ? security_capable+0x35/0x60 > > [ 8.138235] rtnetlink_rcv_msg+0x2e6/0x340 > > [ 8.138431] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 > > [ 8.138650] netlink_rcv_skb+0x16a/0x1a0 > > [ 8.138840] netlink_unicast+0x20a/0x320 > > [ 8.139028] netlink_sendmsg+0x304/0x3b0 > > [ 8.139217] __sock_sendmsg+0x89/0xb0 > > [ 8.139399] ____sys_sendmsg+0x167/0x1c0 > > [ 8.139588] ? ____sys_recvmsg+0xed/0x150 > > [ 8.139780] ___sys_sendmsg+0xdd/0x120 > > [ 8.139960] ? ___sys_recvmsg+0x124/0x1e0 > > [ 8.140152] ? rcutree_enqueue+0x1f/0xb0 > > [ 8.140341] ? rcutree_enqueue+0x1f/0xb0 > > [ 8.140528] ? call_rcu+0xde/0x2a0 > > [ 8.140695] ? evict+0x286/0x2d0 > > [ 8.140856] ? rcutree_enqueue+0x1f/0xb0 > > [ 8.141043] ? kmem_cache_free+0x2c/0x350 > > [ 8.141236] __x64_sys_sendmsg+0x72/0xc0 > > [ 8.141424] do_syscall_64+0x6f/0x890 > > [ 8.141603] entry_SYSCALL_64_after_hwframe+0x76/0x7e > > [ 8.141841] RIP: 0033:0x7f2799d21bd0 > > ... > > [ 8.149905] Kernel panic - not syncing: Fatal exception > > [ 8.175940] Kernel Offset: 0xf800000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) > > [ 8.176425] Rebooting in 10 seconds.. > > ``` > > > > Tested: With this patch, the kernel panic no longer appears. > > Is it easy to reproduce? In our internal environments, we have the idpf driver running on machines with small RAM, and it's not uncommon for them to run out of memory and encounter kalloc issues, especially in kcallocs where we allocate higher order memory. To reliably reproduce the issue in my own testing, I simply set rx_qgrp->splitq.bufq_sets to NULL: rx_qgrp->splitq.bufq_sets = kcalloc(vport->num_bufqs_per_qgrp, sizeof(struct idpf_bufq_set), GFP_KERNEL); rx_qgrp->splitq.bufq_sets = NULL; If the error path works correctly, we should not see a kernel panic. > > > Fixes: 95af467d9a4e ("idpf: configure resources for RX queues") > > > > (Just for the future, a blank in the “tag section” is uncommon.) Thank you for the info! > > > Signed-off-by: Li Li <boolli@google.com> > > --- > > drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > > index e7b131dba200c..b4dab4a8ee11b 100644 > > --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > > +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > > @@ -1337,6 +1337,8 @@ static void idpf_txq_group_rel(struct idpf_vport *vport) > > static void idpf_rxq_sw_queue_rel(struct idpf_rxq_group *rx_qgrp) > > { > > int i, j; > > + if (!rx_qgrp->splitq.bufq_sets) > > + return; > > > > for (i = 0; i < rx_qgrp->vport->num_bufqs_per_qgrp; i++) { > > struct idpf_bufq_set *bufq_set = &rx_qgrp->splitq.bufq_sets[i]; > > Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> > > > Kind regards, > > Paul ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [Intel-wired-lan] [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL. 2026-01-12 23:09 ` [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL Li Li 2026-01-13 6:31 ` [Intel-wired-lan] " Paul Menzel @ 2026-01-13 7:34 ` Loktionov, Aleksandr 2026-02-02 16:27 ` Salin, Samuel 1 sibling, 1 reply; 10+ messages in thread From: Loktionov, Aleksandr @ 2026-01-13 7:34 UTC (permalink / raw) To: Li Li, Nguyen, Anthony L, Kitszel, Przemyslaw, David S. Miller, Jakub Kicinski, Eric Dumazet, intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, David Decotigny, Singhai, Anjali, Samudrala, Sridhar, Brian Vazquez, Tantilov, Emil S > -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf > Of Li Li via Intel-wired-lan > Sent: Tuesday, January 13, 2026 12:10 AM > To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, > Przemyslaw <przemyslaw.kitszel@intel.com>; David S. Miller > <davem@davemloft.net>; Jakub Kicinski <kuba@kernel.org>; Eric Dumazet > <edumazet@google.com>; intel-wired-lan@lists.osuosl.org > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; David > Decotigny <decot@google.com>; Singhai, Anjali > <anjali.singhai@intel.com>; Samudrala, Sridhar > <sridhar.samudrala@intel.com>; Brian Vazquez <brianvv@google.com>; Li > Li <boolli@google.com>; Tantilov, Emil S <emil.s.tantilov@intel.com> > Subject: [Intel-wired-lan] [PATCH 1/2] idpf: skip deallocating > bufq_sets from rx_qgrp if it is NULL. > > In idpf_rxq_group_alloc(), if rx_qgrp->splitq.bufq_sets failed to get > allocated: > > rx_qgrp->splitq.bufq_sets = kcalloc(vport->num_bufqs_per_qgrp, > sizeof(struct idpf_bufq_set), > GFP_KERNEL); > if (!rx_qgrp->splitq.bufq_sets) { > err = -ENOMEM; > goto err_alloc; > } > > idpf_rxq_group_rel() would attempt to deallocate it in > idpf_rxq_sw_queue_rel(), causing a kernel panic: > > ``` > [ 7.967242] early-network-sshd-n-rexd[3148]: knetbase: Info: [ > 8.127804] BUG: kernel NULL pointer dereference, address: > 00000000000000c0 > ... > [ 8.129779] RIP: 0010:idpf_rxq_group_rel+0x101/0x170 > ... > [ 8.133854] Call Trace: > [ 8.133980] <TASK> > [ 8.134092] idpf_vport_queues_alloc+0x286/0x500 > [ 8.134313] idpf_vport_open+0x4d/0x3f0 > [ 8.134498] idpf_open+0x71/0xb0 > [ 8.134668] __dev_open+0x142/0x260 > [ 8.134840] netif_open+0x2f/0xe0 > [ 8.135004] dev_open+0x3d/0x70 > [ 8.135166] bond_enslave+0x5ed/0xf50 > [ 8.135345] ? nla_put_ifalias+0x3d/0x90 > [ 8.135533] ? kvfree_call_rcu+0xb5/0x3b0 > [ 8.135725] ? kvfree_call_rcu+0xb5/0x3b0 > [ 8.135916] do_set_master+0x114/0x160 > [ 8.136098] do_setlink+0x412/0xfb0 > [ 8.136269] ? security_sock_rcv_skb+0x2a/0x50 > [ 8.136509] ? sk_filter_trim_cap+0x7c/0x320 > [ 8.136714] ? skb_queue_tail+0x20/0x50 > [ 8.136899] ? __nla_validate_parse+0x92/0xe50 > [ 8.137112] ? security_capable+0x35/0x60 > [ 8.137304] rtnl_newlink+0x95c/0xa00 > [ 8.137483] ? __rtnl_unlock+0x37/0x70 > [ 8.137664] ? netdev_run_todo+0x63/0x530 > [ 8.137855] ? allocate_slab+0x280/0x870 > [ 8.138044] ? security_capable+0x35/0x60 > [ 8.138235] rtnetlink_rcv_msg+0x2e6/0x340 > [ 8.138431] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 > [ 8.138650] netlink_rcv_skb+0x16a/0x1a0 > [ 8.138840] netlink_unicast+0x20a/0x320 > [ 8.139028] netlink_sendmsg+0x304/0x3b0 > [ 8.139217] __sock_sendmsg+0x89/0xb0 > [ 8.139399] ____sys_sendmsg+0x167/0x1c0 > [ 8.139588] ? ____sys_recvmsg+0xed/0x150 > [ 8.139780] ___sys_sendmsg+0xdd/0x120 > [ 8.139960] ? ___sys_recvmsg+0x124/0x1e0 > [ 8.140152] ? rcutree_enqueue+0x1f/0xb0 > [ 8.140341] ? rcutree_enqueue+0x1f/0xb0 > [ 8.140528] ? call_rcu+0xde/0x2a0 > [ 8.140695] ? evict+0x286/0x2d0 > [ 8.140856] ? rcutree_enqueue+0x1f/0xb0 > [ 8.141043] ? kmem_cache_free+0x2c/0x350 > [ 8.141236] __x64_sys_sendmsg+0x72/0xc0 > [ 8.141424] do_syscall_64+0x6f/0x890 > [ 8.141603] entry_SYSCALL_64_after_hwframe+0x76/0x7e > [ 8.141841] RIP: 0033:0x7f2799d21bd0 > ... > [ 8.149905] Kernel panic - not syncing: Fatal exception > [ 8.175940] Kernel Offset: 0xf800000 from 0xffffffff81000000 > (relocation range: 0xffffffff80000000-0xffffffffbfffffff) > [ 8.176425] Rebooting in 10 seconds.. > ``` > > Tested: With this patch, the kernel panic no longer appears. > Fixes: 95af467d9a4e ("idpf: configure resources for RX queues") > > Signed-off-by: Li Li <boolli@google.com> > --- > drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > index e7b131dba200c..b4dab4a8ee11b 100644 > --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > @@ -1337,6 +1337,8 @@ static void idpf_txq_group_rel(struct idpf_vport > *vport) static void idpf_rxq_sw_queue_rel(struct idpf_rxq_group > *rx_qgrp) { > int i, j; > + if (!rx_qgrp->splitq.bufq_sets) > + return; > > for (i = 0; i < rx_qgrp->vport->num_bufqs_per_qgrp; i++) { > struct idpf_bufq_set *bufq_set = &rx_qgrp- > >splitq.bufq_sets[i]; > -- > 2.52.0.457.g6b5491de43-goog Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [Intel-wired-lan] [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL. 2026-01-13 7:34 ` Loktionov, Aleksandr @ 2026-02-02 16:27 ` Salin, Samuel 0 siblings, 0 replies; 10+ messages in thread From: Salin, Samuel @ 2026-02-02 16:27 UTC (permalink / raw) To: Loktionov, Aleksandr, Li Li, Nguyen, Anthony L, Kitszel, Przemyslaw, David S. Miller, Jakub Kicinski, Eric Dumazet, intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, David Decotigny, Singhai, Anjali, Samudrala, Sridhar, Brian Vazquez, Tantilov, Emil S > -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of > Loktionov, Aleksandr > Sent: Monday, January 12, 2026 11:34 PM > To: Li Li <boolli@google.com>; Nguyen, Anthony L > <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw > <przemyslaw.kitszel@intel.com>; David S. Miller <davem@davemloft.net>; > Jakub Kicinski <kuba@kernel.org>; Eric Dumazet <edumazet@google.com>; > intel-wired-lan@lists.osuosl.org > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; David Decotigny > <decot@google.com>; Singhai, Anjali <anjali.singhai@intel.com>; Samudrala, > Sridhar <sridhar.samudrala@intel.com>; Brian Vazquez > <brianvv@google.com>; Tantilov, Emil S <emil.s.tantilov@intel.com> > Subject: Re: [Intel-wired-lan] [PATCH 1/2] idpf: skip deallocating bufq_sets > from rx_qgrp if it is NULL. > > > > > -----Original Message----- > > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf > > Of Li Li via Intel-wired-lan > > Sent: Tuesday, January 13, 2026 12:10 AM > > To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, > > Przemyslaw <przemyslaw.kitszel@intel.com>; David S. Miller > > <davem@davemloft.net>; Jakub Kicinski <kuba@kernel.org>; Eric Dumazet > > <edumazet@google.com>; intel-wired-lan@lists.osuosl.org > > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; David > > Decotigny <decot@google.com>; Singhai, Anjali > > <anjali.singhai@intel.com>; Samudrala, Sridhar > > <sridhar.samudrala@intel.com>; Brian Vazquez <brianvv@google.com>; Li > > Li <boolli@google.com>; Tantilov, Emil S <emil.s.tantilov@intel.com> > > Subject: [Intel-wired-lan] [PATCH 1/2] idpf: skip deallocating > > bufq_sets from rx_qgrp if it is NULL. > > > > In idpf_rxq_group_alloc(), if rx_qgrp->splitq.bufq_sets failed to get > > allocated: > > > > rx_qgrp->splitq.bufq_sets = kcalloc(vport->num_bufqs_per_qgrp, > > sizeof(struct idpf_bufq_set), > > GFP_KERNEL); > > if (!rx_qgrp->splitq.bufq_sets) { > > err = -ENOMEM; > > goto err_alloc; > > } > > > > idpf_rxq_group_rel() would attempt to deallocate it in > > idpf_rxq_sw_queue_rel(), causing a kernel panic: > > > > ``` > > [ 7.967242] early-network-sshd-n-rexd[3148]: knetbase: Info: [ > > 8.127804] BUG: kernel NULL pointer dereference, address: > > 00000000000000c0 > > ... > > [ 8.129779] RIP: 0010:idpf_rxq_group_rel+0x101/0x170 > > ... > > [ 8.133854] Call Trace: > > [ 8.133980] <TASK> > > [ 8.134092] idpf_vport_queues_alloc+0x286/0x500 > > [ 8.134313] idpf_vport_open+0x4d/0x3f0 > > [ 8.134498] idpf_open+0x71/0xb0 > > [ 8.134668] __dev_open+0x142/0x260 > > [ 8.134840] netif_open+0x2f/0xe0 > > [ 8.135004] dev_open+0x3d/0x70 > > [ 8.135166] bond_enslave+0x5ed/0xf50 > > [ 8.135345] ? nla_put_ifalias+0x3d/0x90 > > [ 8.135533] ? kvfree_call_rcu+0xb5/0x3b0 > > [ 8.135725] ? kvfree_call_rcu+0xb5/0x3b0 > > [ 8.135916] do_set_master+0x114/0x160 > > [ 8.136098] do_setlink+0x412/0xfb0 > > [ 8.136269] ? security_sock_rcv_skb+0x2a/0x50 > > [ 8.136509] ? sk_filter_trim_cap+0x7c/0x320 > > [ 8.136714] ? skb_queue_tail+0x20/0x50 > > [ 8.136899] ? __nla_validate_parse+0x92/0xe50 > > [ 8.137112] ? security_capable+0x35/0x60 > > [ 8.137304] rtnl_newlink+0x95c/0xa00 > > [ 8.137483] ? __rtnl_unlock+0x37/0x70 > > [ 8.137664] ? netdev_run_todo+0x63/0x530 > > [ 8.137855] ? allocate_slab+0x280/0x870 > > [ 8.138044] ? security_capable+0x35/0x60 > > [ 8.138235] rtnetlink_rcv_msg+0x2e6/0x340 > > [ 8.138431] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 > > [ 8.138650] netlink_rcv_skb+0x16a/0x1a0 > > [ 8.138840] netlink_unicast+0x20a/0x320 > > [ 8.139028] netlink_sendmsg+0x304/0x3b0 > > [ 8.139217] __sock_sendmsg+0x89/0xb0 > > [ 8.139399] ____sys_sendmsg+0x167/0x1c0 > > [ 8.139588] ? ____sys_recvmsg+0xed/0x150 > > [ 8.139780] ___sys_sendmsg+0xdd/0x120 > > [ 8.139960] ? ___sys_recvmsg+0x124/0x1e0 > > [ 8.140152] ? rcutree_enqueue+0x1f/0xb0 > > [ 8.140341] ? rcutree_enqueue+0x1f/0xb0 > > [ 8.140528] ? call_rcu+0xde/0x2a0 > > [ 8.140695] ? evict+0x286/0x2d0 > > [ 8.140856] ? rcutree_enqueue+0x1f/0xb0 > > [ 8.141043] ? kmem_cache_free+0x2c/0x350 > > [ 8.141236] __x64_sys_sendmsg+0x72/0xc0 > > [ 8.141424] do_syscall_64+0x6f/0x890 > > [ 8.141603] entry_SYSCALL_64_after_hwframe+0x76/0x7e > > [ 8.141841] RIP: 0033:0x7f2799d21bd0 > > ... > > [ 8.149905] Kernel panic - not syncing: Fatal exception > > [ 8.175940] Kernel Offset: 0xf800000 from 0xffffffff81000000 > > (relocation range: 0xffffffff80000000-0xffffffffbfffffff) > > [ 8.176425] Rebooting in 10 seconds.. > > ``` > > > > Tested: With this patch, the kernel panic no longer appears. > > Fixes: 95af467d9a4e ("idpf: configure resources for RX queues") > > > > Signed-off-by: Li Li <boolli@google.com> > > --- > > drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > > b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > > index e7b131dba200c..b4dab4a8ee11b 100644 > > --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > > +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > > @@ -1337,6 +1337,8 @@ static void idpf_txq_group_rel(struct idpf_vport > > *vport) static void idpf_rxq_sw_queue_rel(struct idpf_rxq_group > > *rx_qgrp) { > > int i, j; > > + if (!rx_qgrp->splitq.bufq_sets) > > + return; > > > > for (i = 0; i < rx_qgrp->vport->num_bufqs_per_qgrp; i++) { > > struct idpf_bufq_set *bufq_set = &rx_qgrp- > > >splitq.bufq_sets[i]; > > -- > > 2.52.0.457.g6b5491de43-goog > > Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 2/2] idpf: skip deallocating txq group's txqs if it is NULL. 2026-01-12 23:09 [PATCH 0/2] idpf: skip NULL pointers during deallocation Li Li 2026-01-12 23:09 ` [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL Li Li @ 2026-01-12 23:09 ` Li Li 2026-01-13 6:43 ` [Intel-wired-lan] " Paul Menzel 2026-01-13 7:34 ` Loktionov, Aleksandr 1 sibling, 2 replies; 10+ messages in thread From: Li Li @ 2026-01-12 23:09 UTC (permalink / raw) To: Tony Nguyen, Przemek Kitszel, David S. Miller, Jakub Kicinski, Eric Dumazet, intel-wired-lan Cc: netdev, linux-kernel, David Decotigny, Anjali Singhai, Sridhar Samudrala, Brian Vazquez, Li Li, emil.s.tantilov In idpf_txq_group_alloc(), if any txq group's txqs failed to allocate memory: for (j = 0; j < tx_qgrp->num_txq; j++) { tx_qgrp->txqs[j] = kzalloc(sizeof(*tx_qgrp->txqs[j]), GFP_KERNEL); if (!tx_qgrp->txqs[j]) goto err_alloc; } It would cause a NULL ptr kernel panic in idpf_txq_group_rel(): for (j = 0; j < txq_grp->num_txq; j++) { if (flow_sch_en) { kfree(txq_grp->txqs[j]->refillq); txq_grp->txqs[j]->refillq = NULL; } kfree(txq_grp->txqs[j]); txq_grp->txqs[j] = NULL; } [ 6.532461] BUG: kernel NULL pointer dereference, address: 0000000000000058 ... [ 6.534433] RIP: 0010:idpf_txq_group_rel+0xc9/0x110 ... [ 6.538513] Call Trace: [ 6.538639] <TASK> [ 6.538760] idpf_vport_queues_alloc+0x75/0x550 [ 6.538978] idpf_vport_open+0x4d/0x3f0 [ 6.539164] idpf_open+0x71/0xb0 [ 6.539324] __dev_open+0x142/0x260 [ 6.539506] netif_open+0x2f/0xe0 [ 6.539670] dev_open+0x3d/0x70 [ 6.539827] bond_enslave+0x5ed/0xf50 [ 6.540005] ? rcutree_enqueue+0x1f/0xb0 [ 6.540193] ? call_rcu+0xde/0x2a0 [ 6.540375] ? barn_get_empty_sheaf+0x5c/0x80 [ 6.540594] ? __kfree_rcu_sheaf+0xb6/0x1a0 [ 6.540793] ? nla_put_ifalias+0x3d/0x90 [ 6.540981] ? kvfree_call_rcu+0xb5/0x3b0 [ 6.541173] ? kvfree_call_rcu+0xb5/0x3b0 [ 6.541365] do_set_master+0x114/0x160 [ 6.541547] do_setlink+0x412/0xfb0 [ 6.541717] ? security_sock_rcv_skb+0x2a/0x50 [ 6.541931] ? sk_filter_trim_cap+0x7c/0x320 [ 6.542136] ? skb_queue_tail+0x20/0x50 [ 6.542322] ? __nla_validate_parse+0x92/0xe50 ro[o t t o6 .d5e4f2a5u4l0t]- ? security_capable+0x35/0x60 [ 6.542792] rtnl_newlink+0x95c/0xa00 [ 6.542972] ? __rtnl_unlock+0x37/0x70 [ 6.543152] ? netdev_run_todo+0x63/0x530 [ 6.543343] ? allocate_slab+0x280/0x870 [ 6.543531] ? security_capable+0x35/0x60 [ 6.543722] rtnetlink_rcv_msg+0x2e6/0x340 [ 6.543918] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 6.544138] netlink_rcv_skb+0x16a/0x1a0 [ 6.544328] netlink_unicast+0x20a/0x320 [ 6.544516] netlink_sendmsg+0x304/0x3b0 [ 6.544748] __sock_sendmsg+0x89/0xb0 [ 6.544928] ____sys_sendmsg+0x167/0x1c0 [ 6.545116] ? ____sys_recvmsg+0xed/0x150 [ 6.545308] ___sys_sendmsg+0xdd/0x120 [ 6.545489] ? ___sys_recvmsg+0x124/0x1e0 [ 6.545680] ? rcutree_enqueue+0x1f/0xb0 [ 6.545867] ? rcutree_enqueue+0x1f/0xb0 [ 6.546055] ? call_rcu+0xde/0x2a0 [ 6.546222] ? evict+0x286/0x2d0 [ 6.546389] ? rcutree_enqueue+0x1f/0xb0 [ 6.546577] ? kmem_cache_free+0x2c/0x350 [ 6.546784] __x64_sys_sendmsg+0x72/0xc0 [ 6.546972] do_syscall_64+0x6f/0x890 [ 6.547150] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 6.547393] RIP: 0033:0x7fc1a3347bd0 ... [ 6.551375] RIP: 0010:idpf_txq_group_rel+0xc9/0x110 ... [ 6.578856] Rebooting in 10 seconds.. We should skip deallocating txqs[j] if it is NULL in the first place. Tested: with this patch, the kernel panic no longer appears. Fixes: 1c325aac10a8 ("idpf: configure resources for TX queues") Signed-off-by: Li Li <boolli@google.com> --- drivers/net/ethernet/intel/idpf/idpf_txrx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c index b4dab4a8ee11b..25207da6c995d 100644 --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c @@ -1311,6 +1311,9 @@ static void idpf_txq_group_rel(struct idpf_vport *vport) struct idpf_txq_group *txq_grp = &vport->txq_grps[i]; for (j = 0; j < txq_grp->num_txq; j++) { + if (!txq_grp->txqs[j]) + continue; + if (flow_sch_en) { kfree(txq_grp->txqs[j]->refillq); txq_grp->txqs[j]->refillq = NULL; -- 2.52.0.457.g6b5491de43-goog ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [Intel-wired-lan] [PATCH 2/2] idpf: skip deallocating txq group's txqs if it is NULL. 2026-01-12 23:09 ` [PATCH 2/2] idpf: skip deallocating txq group's txqs " Li Li @ 2026-01-13 6:43 ` Paul Menzel 2026-01-13 7:34 ` Loktionov, Aleksandr 1 sibling, 0 replies; 10+ messages in thread From: Paul Menzel @ 2026-01-13 6:43 UTC (permalink / raw) To: Li Li Cc: Tony Nguyen, Przemek Kitszel, David S. Miller, Jakub Kicinski, Eric Dumazet, intel-wired-lan, netdev, linux-kernel, David Decotigny, Anjali Singhai, Sridhar Samudrala, Brian Vazquez, emil.s.tantilov Dear Li, Thank you for your patch. Am 13.01.26 um 00:09 schrieb Li Li: > In idpf_txq_group_alloc(), if any txq group's txqs failed to > allocate memory: > > for (j = 0; j < tx_qgrp->num_txq; j++) { > tx_qgrp->txqs[j] = kzalloc(sizeof(*tx_qgrp->txqs[j]), > GFP_KERNEL); > if (!tx_qgrp->txqs[j]) > goto err_alloc; > } > > It would cause a NULL ptr kernel panic in idpf_txq_group_rel(): > > for (j = 0; j < txq_grp->num_txq; j++) { > if (flow_sch_en) { > kfree(txq_grp->txqs[j]->refillq); > txq_grp->txqs[j]->refillq = NULL; > } > > kfree(txq_grp->txqs[j]); > txq_grp->txqs[j] = NULL; > } > > [ 6.532461] BUG: kernel NULL pointer dereference, address: 0000000000000058 > ... > [ 6.534433] RIP: 0010:idpf_txq_group_rel+0xc9/0x110 > ... > [ 6.538513] Call Trace: > [ 6.538639] <TASK> > [ 6.538760] idpf_vport_queues_alloc+0x75/0x550 > [ 6.538978] idpf_vport_open+0x4d/0x3f0 > [ 6.539164] idpf_open+0x71/0xb0 > [ 6.539324] __dev_open+0x142/0x260 > [ 6.539506] netif_open+0x2f/0xe0 > [ 6.539670] dev_open+0x3d/0x70 > [ 6.539827] bond_enslave+0x5ed/0xf50 > [ 6.540005] ? rcutree_enqueue+0x1f/0xb0 > [ 6.540193] ? call_rcu+0xde/0x2a0 > [ 6.540375] ? barn_get_empty_sheaf+0x5c/0x80 > [ 6.540594] ? __kfree_rcu_sheaf+0xb6/0x1a0 > [ 6.540793] ? nla_put_ifalias+0x3d/0x90 > [ 6.540981] ? kvfree_call_rcu+0xb5/0x3b0 > [ 6.541173] ? kvfree_call_rcu+0xb5/0x3b0 > [ 6.541365] do_set_master+0x114/0x160 > [ 6.541547] do_setlink+0x412/0xfb0 > [ 6.541717] ? security_sock_rcv_skb+0x2a/0x50 > [ 6.541931] ? sk_filter_trim_cap+0x7c/0x320 > [ 6.542136] ? skb_queue_tail+0x20/0x50 > [ 6.542322] ? __nla_validate_parse+0x92/0xe50 ro[o t t o6 .d5e4f2a5u4l0t]- ? security_capable+0x35/0x60 > [ 6.542792] rtnl_newlink+0x95c/0xa00 > [ 6.542972] ? __rtnl_unlock+0x37/0x70 > [ 6.543152] ? netdev_run_todo+0x63/0x530 > [ 6.543343] ? allocate_slab+0x280/0x870 > [ 6.543531] ? security_capable+0x35/0x60 > [ 6.543722] rtnetlink_rcv_msg+0x2e6/0x340 > [ 6.543918] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 > [ 6.544138] netlink_rcv_skb+0x16a/0x1a0 > [ 6.544328] netlink_unicast+0x20a/0x320 > [ 6.544516] netlink_sendmsg+0x304/0x3b0 > [ 6.544748] __sock_sendmsg+0x89/0xb0 > [ 6.544928] ____sys_sendmsg+0x167/0x1c0 > [ 6.545116] ? ____sys_recvmsg+0xed/0x150 > [ 6.545308] ___sys_sendmsg+0xdd/0x120 > [ 6.545489] ? ___sys_recvmsg+0x124/0x1e0 > [ 6.545680] ? rcutree_enqueue+0x1f/0xb0 > [ 6.545867] ? rcutree_enqueue+0x1f/0xb0 > [ 6.546055] ? call_rcu+0xde/0x2a0 > [ 6.546222] ? evict+0x286/0x2d0 > [ 6.546389] ? rcutree_enqueue+0x1f/0xb0 > [ 6.546577] ? kmem_cache_free+0x2c/0x350 > [ 6.546784] __x64_sys_sendmsg+0x72/0xc0 > [ 6.546972] do_syscall_64+0x6f/0x890 > [ 6.547150] entry_SYSCALL_64_after_hwframe+0x76/0x7e > [ 6.547393] RIP: 0033:0x7fc1a3347bd0 > ... > [ 6.551375] RIP: 0010:idpf_txq_group_rel+0xc9/0x110 > ... > [ 6.578856] Rebooting in 10 seconds.. > > We should skip deallocating txqs[j] if it is NULL in the first place. > > Tested: with this patch, the kernel panic no longer appears. The reproduction steps would be nice to have documented. > Fixes: 1c325aac10a8 ("idpf: configure resources for TX queues") > > Signed-off-by: Li Li <boolli@google.com> > --- > drivers/net/ethernet/intel/idpf/idpf_txrx.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > index b4dab4a8ee11b..25207da6c995d 100644 > --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > @@ -1311,6 +1311,9 @@ static void idpf_txq_group_rel(struct idpf_vport *vport) > struct idpf_txq_group *txq_grp = &vport->txq_grps[i]; > > for (j = 0; j < txq_grp->num_txq; j++) { > + if (!txq_grp->txqs[j]) > + continue; > + > if (flow_sch_en) { > kfree(txq_grp->txqs[j]->refillq); > txq_grp->txqs[j]->refillq = NULL; Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Kind regards, Paul ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [Intel-wired-lan] [PATCH 2/2] idpf: skip deallocating txq group's txqs if it is NULL. 2026-01-12 23:09 ` [PATCH 2/2] idpf: skip deallocating txq group's txqs " Li Li 2026-01-13 6:43 ` [Intel-wired-lan] " Paul Menzel @ 2026-01-13 7:34 ` Loktionov, Aleksandr 2026-02-02 16:27 ` Salin, Samuel 1 sibling, 1 reply; 10+ messages in thread From: Loktionov, Aleksandr @ 2026-01-13 7:34 UTC (permalink / raw) To: Li Li, Nguyen, Anthony L, Kitszel, Przemyslaw, David S. Miller, Jakub Kicinski, Eric Dumazet, intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, David Decotigny, Singhai, Anjali, Samudrala, Sridhar, Brian Vazquez, Tantilov, Emil S > -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf > Of Li Li > Sent: Tuesday, January 13, 2026 12:10 AM > To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, > Przemyslaw <przemyslaw.kitszel@intel.com>; David S. Miller > <davem@davemloft.net>; Jakub Kicinski <kuba@kernel.org>; Eric Dumazet > <edumazet@google.com>; intel-wired-lan@lists.osuosl.org > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; David > Decotigny <decot@google.com>; Singhai, Anjali > <anjali.singhai@intel.com>; Samudrala, Sridhar > <sridhar.samudrala@intel.com>; Brian Vazquez <brianvv@google.com>; Li > Li <boolli@google.com>; Tantilov, Emil S <emil.s.tantilov@intel.com> > Subject: [Intel-wired-lan] [PATCH 2/2] idpf: skip deallocating txq > group's txqs if it is NULL. > > In idpf_txq_group_alloc(), if any txq group's txqs failed to allocate > memory: > > for (j = 0; j < tx_qgrp->num_txq; j++) { > tx_qgrp->txqs[j] = kzalloc(sizeof(*tx_qgrp->txqs[j]), > GFP_KERNEL); > if (!tx_qgrp->txqs[j]) > goto err_alloc; > } > > It would cause a NULL ptr kernel panic in idpf_txq_group_rel(): > > for (j = 0; j < txq_grp->num_txq; j++) { > if (flow_sch_en) { > kfree(txq_grp->txqs[j]->refillq); > txq_grp->txqs[j]->refillq = NULL; > } > > kfree(txq_grp->txqs[j]); > txq_grp->txqs[j] = NULL; > } > > [ 6.532461] BUG: kernel NULL pointer dereference, address: > 0000000000000058 > ... > [ 6.534433] RIP: 0010:idpf_txq_group_rel+0xc9/0x110 > ... > [ 6.538513] Call Trace: > [ 6.538639] <TASK> > [ 6.538760] idpf_vport_queues_alloc+0x75/0x550 > [ 6.538978] idpf_vport_open+0x4d/0x3f0 > [ 6.539164] idpf_open+0x71/0xb0 > [ 6.539324] __dev_open+0x142/0x260 > [ 6.539506] netif_open+0x2f/0xe0 > [ 6.539670] dev_open+0x3d/0x70 > [ 6.539827] bond_enslave+0x5ed/0xf50 > [ 6.540005] ? rcutree_enqueue+0x1f/0xb0 > [ 6.540193] ? call_rcu+0xde/0x2a0 > [ 6.540375] ? barn_get_empty_sheaf+0x5c/0x80 > [ 6.540594] ? __kfree_rcu_sheaf+0xb6/0x1a0 > [ 6.540793] ? nla_put_ifalias+0x3d/0x90 > [ 6.540981] ? kvfree_call_rcu+0xb5/0x3b0 > [ 6.541173] ? kvfree_call_rcu+0xb5/0x3b0 > [ 6.541365] do_set_master+0x114/0x160 > [ 6.541547] do_setlink+0x412/0xfb0 > [ 6.541717] ? security_sock_rcv_skb+0x2a/0x50 > [ 6.541931] ? sk_filter_trim_cap+0x7c/0x320 > [ 6.542136] ? skb_queue_tail+0x20/0x50 > [ 6.542322] ? __nla_validate_parse+0x92/0xe50 > ro[o t t o6 .d5e4f2a5u4l0t]- ? security_capable+0x35/0x60 > [ 6.542792] rtnl_newlink+0x95c/0xa00 > [ 6.542972] ? __rtnl_unlock+0x37/0x70 > [ 6.543152] ? netdev_run_todo+0x63/0x530 > [ 6.543343] ? allocate_slab+0x280/0x870 > [ 6.543531] ? security_capable+0x35/0x60 > [ 6.543722] rtnetlink_rcv_msg+0x2e6/0x340 > [ 6.543918] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 > [ 6.544138] netlink_rcv_skb+0x16a/0x1a0 > [ 6.544328] netlink_unicast+0x20a/0x320 > [ 6.544516] netlink_sendmsg+0x304/0x3b0 > [ 6.544748] __sock_sendmsg+0x89/0xb0 > [ 6.544928] ____sys_sendmsg+0x167/0x1c0 > [ 6.545116] ? ____sys_recvmsg+0xed/0x150 > [ 6.545308] ___sys_sendmsg+0xdd/0x120 > [ 6.545489] ? ___sys_recvmsg+0x124/0x1e0 > [ 6.545680] ? rcutree_enqueue+0x1f/0xb0 > [ 6.545867] ? rcutree_enqueue+0x1f/0xb0 > [ 6.546055] ? call_rcu+0xde/0x2a0 > [ 6.546222] ? evict+0x286/0x2d0 > [ 6.546389] ? rcutree_enqueue+0x1f/0xb0 > [ 6.546577] ? kmem_cache_free+0x2c/0x350 > [ 6.546784] __x64_sys_sendmsg+0x72/0xc0 > [ 6.546972] do_syscall_64+0x6f/0x890 > [ 6.547150] entry_SYSCALL_64_after_hwframe+0x76/0x7e > [ 6.547393] RIP: 0033:0x7fc1a3347bd0 > ... > [ 6.551375] RIP: 0010:idpf_txq_group_rel+0xc9/0x110 > ... > [ 6.578856] Rebooting in 10 seconds.. > > We should skip deallocating txqs[j] if it is NULL in the first place. > > Tested: with this patch, the kernel panic no longer appears. > Fixes: 1c325aac10a8 ("idpf: configure resources for TX queues") > > Signed-off-by: Li Li <boolli@google.com> > --- > drivers/net/ethernet/intel/idpf/idpf_txrx.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > index b4dab4a8ee11b..25207da6c995d 100644 > --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > @@ -1311,6 +1311,9 @@ static void idpf_txq_group_rel(struct idpf_vport > *vport) > struct idpf_txq_group *txq_grp = &vport->txq_grps[i]; > > for (j = 0; j < txq_grp->num_txq; j++) { > + if (!txq_grp->txqs[j]) > + continue; > + > if (flow_sch_en) { > kfree(txq_grp->txqs[j]->refillq); > txq_grp->txqs[j]->refillq = NULL; > -- > 2.52.0.457.g6b5491de43-goog Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: [Intel-wired-lan] [PATCH 2/2] idpf: skip deallocating txq group's txqs if it is NULL. 2026-01-13 7:34 ` Loktionov, Aleksandr @ 2026-02-02 16:27 ` Salin, Samuel 0 siblings, 0 replies; 10+ messages in thread From: Salin, Samuel @ 2026-02-02 16:27 UTC (permalink / raw) To: Loktionov, Aleksandr, Li Li, Nguyen, Anthony L, Kitszel, Przemyslaw, David S. Miller, Jakub Kicinski, Eric Dumazet, intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, David Decotigny, Singhai, Anjali, Samudrala, Sridhar, Brian Vazquez, Tantilov, Emil S > -----Original Message----- > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of > Loktionov, Aleksandr > Sent: Monday, January 12, 2026 11:35 PM > To: Li Li <boolli@google.com>; Nguyen, Anthony L > <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw > <przemyslaw.kitszel@intel.com>; David S. Miller <davem@davemloft.net>; > Jakub Kicinski <kuba@kernel.org>; Eric Dumazet <edumazet@google.com>; > intel-wired-lan@lists.osuosl.org > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; David Decotigny > <decot@google.com>; Singhai, Anjali <anjali.singhai@intel.com>; Samudrala, > Sridhar <sridhar.samudrala@intel.com>; Brian Vazquez > <brianvv@google.com>; Tantilov, Emil S <emil.s.tantilov@intel.com> > Subject: Re: [Intel-wired-lan] [PATCH 2/2] idpf: skip deallocating txq group's > txqs if it is NULL. > > > > > -----Original Message----- > > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf > > Of Li Li > > Sent: Tuesday, January 13, 2026 12:10 AM > > To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, > > Przemyslaw <przemyslaw.kitszel@intel.com>; David S. Miller > > <davem@davemloft.net>; Jakub Kicinski <kuba@kernel.org>; Eric Dumazet > > <edumazet@google.com>; intel-wired-lan@lists.osuosl.org > > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; David > > Decotigny <decot@google.com>; Singhai, Anjali > > <anjali.singhai@intel.com>; Samudrala, Sridhar > > <sridhar.samudrala@intel.com>; Brian Vazquez <brianvv@google.com>; Li > > Li <boolli@google.com>; Tantilov, Emil S <emil.s.tantilov@intel.com> > > Subject: [Intel-wired-lan] [PATCH 2/2] idpf: skip deallocating txq > > group's txqs if it is NULL. > > > > In idpf_txq_group_alloc(), if any txq group's txqs failed to allocate > > memory: > > > > for (j = 0; j < tx_qgrp->num_txq; j++) { > > tx_qgrp->txqs[j] = kzalloc(sizeof(*tx_qgrp->txqs[j]), > > GFP_KERNEL); > > if (!tx_qgrp->txqs[j]) > > goto err_alloc; > > } > > > > It would cause a NULL ptr kernel panic in idpf_txq_group_rel(): > > > > for (j = 0; j < txq_grp->num_txq; j++) { > > if (flow_sch_en) { > > kfree(txq_grp->txqs[j]->refillq); > > txq_grp->txqs[j]->refillq = NULL; > > } > > > > kfree(txq_grp->txqs[j]); > > txq_grp->txqs[j] = NULL; > > } > > > > [ 6.532461] BUG: kernel NULL pointer dereference, address: > > 0000000000000058 > > ... > > [ 6.534433] RIP: 0010:idpf_txq_group_rel+0xc9/0x110 > > ... > > [ 6.538513] Call Trace: > > [ 6.538639] <TASK> > > [ 6.538760] idpf_vport_queues_alloc+0x75/0x550 > > [ 6.538978] idpf_vport_open+0x4d/0x3f0 > > [ 6.539164] idpf_open+0x71/0xb0 > > [ 6.539324] __dev_open+0x142/0x260 > > [ 6.539506] netif_open+0x2f/0xe0 > > [ 6.539670] dev_open+0x3d/0x70 > > [ 6.539827] bond_enslave+0x5ed/0xf50 > > [ 6.540005] ? rcutree_enqueue+0x1f/0xb0 > > [ 6.540193] ? call_rcu+0xde/0x2a0 > > [ 6.540375] ? barn_get_empty_sheaf+0x5c/0x80 > > [ 6.540594] ? __kfree_rcu_sheaf+0xb6/0x1a0 > > [ 6.540793] ? nla_put_ifalias+0x3d/0x90 > > [ 6.540981] ? kvfree_call_rcu+0xb5/0x3b0 > > [ 6.541173] ? kvfree_call_rcu+0xb5/0x3b0 > > [ 6.541365] do_set_master+0x114/0x160 > > [ 6.541547] do_setlink+0x412/0xfb0 > > [ 6.541717] ? security_sock_rcv_skb+0x2a/0x50 > > [ 6.541931] ? sk_filter_trim_cap+0x7c/0x320 > > [ 6.542136] ? skb_queue_tail+0x20/0x50 > > [ 6.542322] ? __nla_validate_parse+0x92/0xe50 > > ro[o t t o6 .d5e4f2a5u4l0t]- ? security_capable+0x35/0x60 > > [ 6.542792] rtnl_newlink+0x95c/0xa00 > > [ 6.542972] ? __rtnl_unlock+0x37/0x70 > > [ 6.543152] ? netdev_run_todo+0x63/0x530 > > [ 6.543343] ? allocate_slab+0x280/0x870 > > [ 6.543531] ? security_capable+0x35/0x60 > > [ 6.543722] rtnetlink_rcv_msg+0x2e6/0x340 > > [ 6.543918] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 > > [ 6.544138] netlink_rcv_skb+0x16a/0x1a0 > > [ 6.544328] netlink_unicast+0x20a/0x320 > > [ 6.544516] netlink_sendmsg+0x304/0x3b0 > > [ 6.544748] __sock_sendmsg+0x89/0xb0 > > [ 6.544928] ____sys_sendmsg+0x167/0x1c0 > > [ 6.545116] ? ____sys_recvmsg+0xed/0x150 > > [ 6.545308] ___sys_sendmsg+0xdd/0x120 > > [ 6.545489] ? ___sys_recvmsg+0x124/0x1e0 > > [ 6.545680] ? rcutree_enqueue+0x1f/0xb0 > > [ 6.545867] ? rcutree_enqueue+0x1f/0xb0 > > [ 6.546055] ? call_rcu+0xde/0x2a0 > > [ 6.546222] ? evict+0x286/0x2d0 > > [ 6.546389] ? rcutree_enqueue+0x1f/0xb0 > > [ 6.546577] ? kmem_cache_free+0x2c/0x350 > > [ 6.546784] __x64_sys_sendmsg+0x72/0xc0 > > [ 6.546972] do_syscall_64+0x6f/0x890 > > [ 6.547150] entry_SYSCALL_64_after_hwframe+0x76/0x7e > > [ 6.547393] RIP: 0033:0x7fc1a3347bd0 > > ... > > [ 6.551375] RIP: 0010:idpf_txq_group_rel+0xc9/0x110 > > ... > > [ 6.578856] Rebooting in 10 seconds.. > > > > We should skip deallocating txqs[j] if it is NULL in the first place. > > > > Tested: with this patch, the kernel panic no longer appears. > > Fixes: 1c325aac10a8 ("idpf: configure resources for TX queues") > > > > Signed-off-by: Li Li <boolli@google.com> > > --- > > drivers/net/ethernet/intel/idpf/idpf_txrx.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > > b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > > index b4dab4a8ee11b..25207da6c995d 100644 > > --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c > > +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c > > @@ -1311,6 +1311,9 @@ static void idpf_txq_group_rel(struct idpf_vport > > *vport) > > struct idpf_txq_group *txq_grp = &vport->txq_grps[i]; > > > > for (j = 0; j < txq_grp->num_txq; j++) { > > + if (!txq_grp->txqs[j]) > > + continue; > > + > > if (flow_sch_en) { > > kfree(txq_grp->txqs[j]->refillq); > > txq_grp->txqs[j]->refillq = NULL; > > -- > > 2.52.0.457.g6b5491de43-goog > > Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2026-02-02 16:27 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-01-12 23:09 [PATCH 0/2] idpf: skip NULL pointers during deallocation Li Li 2026-01-12 23:09 ` [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL Li Li 2026-01-13 6:31 ` [Intel-wired-lan] " Paul Menzel 2026-01-15 20:07 ` Li Li 2026-01-13 7:34 ` Loktionov, Aleksandr 2026-02-02 16:27 ` Salin, Samuel 2026-01-12 23:09 ` [PATCH 2/2] idpf: skip deallocating txq group's txqs " Li Li 2026-01-13 6:43 ` [Intel-wired-lan] " Paul Menzel 2026-01-13 7:34 ` Loktionov, Aleksandr 2026-02-02 16:27 ` Salin, Samuel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox