* [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
* [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 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 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 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 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 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 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
* 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
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