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 On Behalf Of > Loktionov, Aleksandr > Sent: Monday, January 12, 2026 11:34 PM > To: Li Li ; Nguyen, Anthony L > ; Kitszel, Przemyslaw > ; David S. Miller ; > Jakub Kicinski ; Eric Dumazet ; > [email protected] > Cc: [email protected]; [email protected]; David Decotigny > ; Singhai, Anjali ; Samudrala, > Sridhar ; Brian Vazquez > ; Tantilov, Emil S > 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 On Behalf > > Of Li Li via Intel-wired-lan > > Sent: Tuesday, January 13, 2026 12:10 AM > > To: Nguyen, Anthony L ; Kitszel, > > Przemyslaw ; David S. Miller > > ; Jakub Kicinski ; Eric Dumazet > > ; [email protected] > > Cc: [email protected]; [email protected]; David > > Decotigny ; Singhai, Anjali > > ; Samudrala, Sridhar > > ; Brian Vazquez ; Li > > Li ; Tantilov, Emil S > > 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: > > 00c0 > > ... > > [8.129779] RIP: 0010:idpf_rxq_group_rel+0x101/0x170 > > ... > > [8.133854] Call Trace: > > [8.133980] > > [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: 0xf80 from 0x8100 > > (relocation range: 0x8000-0xbfff) > > [8.176425] Rebooting in 10 seconds.. > > ``` > > > > Tested: With this patch, the kernel panic no longer appears. > > Fixes: 95af467d9a4e ("idpf: configure resources for RX queues") > > > > Signe
Re: [Intel-wired-lan] [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL.
On Mon, Jan 12, 2026 at 10:31 PM Paul Menzel 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: 00c0
> > ...
> > [8.129779] RIP: 0010:idpf_rxq_group_rel+0x101/0x170
> > ...
> > [8.133854] Call Trace:
> > [8.133980]
> > [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: 0xf80 from 0x8100 (relocation
> > range: 0x8000-0xbfff)
> > [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
> > ---
> > 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
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 On Behalf > Of Li Li via Intel-wired-lan > Sent: Tuesday, January 13, 2026 12:10 AM > To: Nguyen, Anthony L ; Kitszel, > Przemyslaw ; David S. Miller > ; Jakub Kicinski ; Eric Dumazet > ; [email protected] > Cc: [email protected]; [email protected]; David > Decotigny ; Singhai, Anjali > ; Samudrala, Sridhar > ; Brian Vazquez ; Li > Li ; Tantilov, Emil S > 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: > 00c0 > ... > [8.129779] RIP: 0010:idpf_rxq_group_rel+0x101/0x170 > ... > [8.133854] Call Trace: > [8.133980] > [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: 0xf80 from 0x8100 > (relocation range: 0x8000-0xbfff) > [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 > --- > 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
Re: [Intel-wired-lan] [PATCH 1/2] idpf: skip deallocating bufq_sets from rx_qgrp if it is NULL.
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: 00c0
...
[8.129779] RIP: 0010:idpf_rxq_group_rel+0x101/0x170
...
[8.133854] Call Trace:
[8.133980]
[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: 0xf80 from 0x8100 (relocation
range: 0x8000-0xbfff)
[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
---
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
Kind regards,
Paul
