| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <cba926c1-66b9-45fb-a203-13ff646567f9@kernel.org>
Date: Tue, 10 Jun 2025 23:40:22 +0200
From: Jesper Dangaard Brouer <hawk@...nel.org>
To: Ihor Solodrai <ihor.solodrai@...ux.dev>, netdev@...r.kernel.org,
Jakub Kicinski <kuba@...nel.org>,
Bastien Curutchet <bastien.curutchet@...tlin.com>
Cc: bpf@...r.kernel.org, tom@...bertland.com,
Eric Dumazet <eric.dumazet@...il.com>, "David S. Miller"
<davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>,
Toke Høiland-Jørgensen <toke@...e.dk>,
dsahern@...nel.org, makita.toshiaki@....ntt.co.jp,
kernel-team@...udflare.com, phil@....cc,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [PATCH net-next V7 2/2] veth: apply qdisc backpressure on full
ptr_ring to reduce TX drops
On 10/06/2025 20.26, Ihor Solodrai wrote:
> On 6/10/25 8:56 AM, Jesper Dangaard Brouer wrote:
>>
>>
>> On 10/06/2025 13.43, Jesper Dangaard Brouer wrote:
>>>
>>> On 10/06/2025 00.09, Ihor Solodrai wrote:
>>>> On 4/25/25 7:55 AM, Jesper Dangaard Brouer wrote:
>> [...]
>>>>> ---
>>>>> drivers/net/veth.c | 57
>>>>> ++++++++++++++++++++++++++++++++++++++++ +++---------
>>>>> 1 file changed, 47 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
>>>>> index 7bb53961c0ea..e58a0f1b5c5b 100644
>>>>> --- a/drivers/net/veth.c
>>>>> +++ b/drivers/net/veth.c
>>>>> @@ -307,12 +307,10 @@ static void __veth_xdp_flush(struct veth_rq *rq)
>>>>> static int veth_xdp_rx(struct veth_rq *rq, struct sk_buff *skb)
>>>>> {
>>>>> - if (unlikely(ptr_ring_produce(&rq->xdp_ring, skb))) {
>>>>> - dev_kfree_skb_any(skb);
>>>>> - return NET_RX_DROP;
>>>>> - }
>>>>> + if (unlikely(ptr_ring_produce(&rq->xdp_ring, skb)))
>>>>> + return NETDEV_TX_BUSY; /* signal qdisc layer */
>>>>> - return NET_RX_SUCCESS;
>>>>> + return NET_RX_SUCCESS; /* same as NETDEV_TX_OK */
>>>>> }
>>>>> static int veth_forward_skb(struct net_device *dev, struct
>>>>> sk_buff *skb,
>>>>> @@ -346,11 +344,11 @@ static netdev_tx_t veth_xmit(struct sk_buff
>>>>> *skb, struct net_device *dev)
>>>>> {
>>>>> struct veth_priv *rcv_priv, *priv = netdev_priv(dev);
>>>>> struct veth_rq *rq = NULL;
>>>>> - int ret = NETDEV_TX_OK;
>>>>> + struct netdev_queue *txq;
>>>>> struct net_device *rcv;
>>>>> int length = skb->len;
>>>>> bool use_napi = false;
>>>>> - int rxq;
>>>>> + int ret, rxq;
>>>>> rcu_read_lock();
>>>>> rcv = rcu_dereference(priv->peer);
>>>>> @@ -373,17 +371,45 @@ static netdev_tx_t veth_xmit(struct sk_buff
>>>>> *skb, struct net_device *dev)
>>>>> }
>>>>> skb_tx_timestamp(skb);
>>>>> - if (likely(veth_forward_skb(rcv, skb, rq, use_napi) ==
>>>>> NET_RX_SUCCESS)) {
>>>>> +
>>>>> + ret = veth_forward_skb(rcv, skb, rq, use_napi);
>>>>> + switch (ret) {
>>>>> + case NET_RX_SUCCESS: /* same as NETDEV_TX_OK */
>>>>> if (!use_napi)
>>>>> dev_sw_netstats_tx_add(dev, 1, length);
>>>>> else
>>>>> __veth_xdp_flush(rq);
>>>>> - } else {
>>>>> + break;
>>>>> + case NETDEV_TX_BUSY:
>>>>> + /* If a qdisc is attached to our virtual device, returning
>>>>> + * NETDEV_TX_BUSY is allowed.
>>>>> + */
>>>>> + txq = netdev_get_tx_queue(dev, rxq);
>>>>> +
>>>>> + if (qdisc_txq_has_no_queue(txq)) {
>>>>> + dev_kfree_skb_any(skb);
>>>>> + goto drop;
>>>>> + }
>>>>> + /* Restore Eth hdr pulled by
>>>>> dev_forward_skb/eth_type_trans */
>>>>> + __skb_push(skb, ETH_HLEN);
>>>>> + /* Depend on prior success packets started NAPI consumer via
>>>>> + * __veth_xdp_flush(). Cancel TXQ stop if consumer stopped,
>>>>> + * paired with empty check in veth_poll().
>>>>> + */
>>>>> + netif_tx_stop_queue(txq);
>>>>> + smp_mb__after_atomic();
>>>>> + if (unlikely(__ptr_ring_empty(&rq->xdp_ring)))
>>>>> + netif_tx_wake_queue(txq);
>>>>> + break;
>>>>> + case NET_RX_DROP: /* same as NET_XMIT_DROP */
>>>>> drop:
>>>>> atomic64_inc(&priv->dropped);
>>>>> ret = NET_XMIT_DROP;
>>>>> + break;
>>>>> + default:
>>>>> + net_crit_ratelimited("%s(%s): Invalid return code(%d)",
>>>>> + __func__, dev->name, ret);
>>>>> }
>>>>> -
>>>>> rcu_read_unlock();
>>>>> return ret;
>>>>> @@ -874,9 +900,17 @@ static int veth_xdp_rcv(struct veth_rq *rq,
>>>>> int budget,
>>>>> struct veth_xdp_tx_bq *bq,
>>>>> struct veth_stats *stats)
>>>>> {
>>>>> + struct veth_priv *priv = netdev_priv(rq->dev);
>>>>> + int queue_idx = rq->xdp_rxq.queue_index;
>>>>> + struct netdev_queue *peer_txq;
>>>>> + struct net_device *peer_dev;
>>>>> int i, done = 0, n_xdpf = 0;
>>>>> void *xdpf[VETH_XDP_BATCH];
>>>>> + /* NAPI functions as RCU section */
>>>>> + peer_dev = rcu_dereference_check(priv->peer,
>>>>> rcu_read_lock_bh_held());
>>>>> + peer_txq = netdev_get_tx_queue(peer_dev, queue_idx);
>>>>> +
>>>>> for (i = 0; i < budget; i++) {
>>>>> void *ptr = __ptr_ring_consume(&rq->xdp_ring);
>>>>>
>>>>
>>>> Hi Jesper.
>>>>
>>>> Could you please take a look at the reported call traces and help
>>>> understand whether this patch may have introduced a null dereference?
>>>
>>> I'm investigating... thanks for reporting.
>
> Thank you for looking into this.
>
>>> (more below)
>>>
>>>> Pasting a snippet, for full logs (2 examples) see the link:
>>>> https://lore.kernel.org/bpf/6fd7a5b5-
>>>> ee26-4cc5-8eb0-449c4e326ccc@...ux.dev/
>>
>> Do you have any qdisc's attached to the veth device when reproducing?
>
> Looking at the selftest code, I don't see any qdisc set up in the
> create_network. But I am not familiar with all this, and could be
> wrong.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools/testing/selftests/bpf/prog_tests/test_xdp_veth.c#n172
>
>>
>> Via above link I see that you managed to reproduce by running BPF
>> selftest "xdp_veth_broadcast_redirect". (Is this correct?)
>>
>> How often does this happen?
>
> So far I wasn't able to reproduce it locally.
>
> It does not happen often. There were two failures on BPF CI out of
> 100+ runs in the past couple of days:
>
> * One on bpf-next:
> *
> https://github.com/kernel-patches/bpf/commit/e41079f53e8792c99cc8888f545c31bc341ea9ac
> *
> https://github.com/kernel-patches/bpf/actions/runs/15543380196/job/43759847203
> * One on netdev tree (netdev merged into bpf-next):
> *
> https://github.com/kernel-patches/bpf/commit/6f3b8b4f8c133ff4eaf3fb74865731d2105c77eb
> *
> https://github.com/kernel-patches/bpf/actions/runs/15563091012/job/43820682289
>
> Click on a gear in top-right and "View raw logs" for full logs.
> Note that you can download kbuild-output from the job artifacts.
>
> Also a syzbot report does not involve the selftests:
> * https://lore.kernel.org/lkml/683da55e.a00a0220.d8eae.0052.GAE@google.com/
>
>>
>> Does this only happen with XDP redirected frames?
>> (Func veth_xdp_rcv() also active for SKBs when veth is in GRO mode)
>
>
> Sorry, I don't know an answer to this... Bastien, could you please comment?
>
> It seems to happen after xdp_veth_broadcast_redirect test successfully
> completed, so before/during xdp_veth_egress tests.
>
>>
>> I'm not able to reproduce this running selftests (bpf-next at
>> 5fcf896efe28c)
>> Below example selecting all "xdp_veth*" related tests:
>>
>> $ sudo ./test_progs --name=xdp_veth
>> #630/1 xdp_veth_broadcast_redirect/0/BROADCAST:OK
>> #630/2 xdp_veth_broadcast_redirect/0/(BROADCAST | EXCLUDE_INGRESS):OK
>> #630/3 xdp_veth_broadcast_redirect/DRV_MODE/BROADCAST:OK
>> #630/4 xdp_veth_broadcast_redirect/DRV_MODE/(BROADCAST |
>> EXCLUDE_INGRESS):OK
>> #630/5 xdp_veth_broadcast_redirect/SKB_MODE/BROADCAST:OK
>> #630/6 xdp_veth_broadcast_redirect/SKB_MODE/(BROADCAST |
>> EXCLUDE_INGRESS):OK
>> #630 xdp_veth_broadcast_redirect:OK
>> #631/1 xdp_veth_egress/0/egress:OK
>> #631/2 xdp_veth_egress/DRV_MODE/egress:OK
>> #631/3 xdp_veth_egress/SKB_MODE/egress:OK
>> #631 xdp_veth_egress:OK
>> #632/1 xdp_veth_redirect/0:OK
>> #632/2 xdp_veth_redirect/DRV_MODE:OK
>> #632/3 xdp_veth_redirect/SKB_MODE:OK
>> #632 xdp_veth_redirect:OK
>> Summary: 3/12 PASSED, 0 SKIPPED, 0 FAILED
>>
>>
>>>> [ 343.217465] BUG: kernel NULL pointer dereference, address:
>>>> 0000000000000018
>>>> [ 343.218173] #PF: supervisor read access in kernel mode
>>>> [ 343.218644] #PF: error_code(0x0000) - not-present page
>>>> [ 343.219128] PGD 0 P4D 0
>>>> [ 343.219379] Oops: Oops: 0000 [#1] SMP NOPTI
>>>> [ 343.219768] CPU: 1 UID: 0 PID: 7635 Comm: kworker/1:11 Tainted: G
>>>> W OE 6.15.0-g2b36f2252b0a-dirty #7 PREEMPT(full)
>> ^^^^^^^^^^^^
>> The SHA 2b36f2252b0 doesn't seem to exist.
>> What upstream kernel commit SHA is this kernel based on?
>
> This sha isn't very helpful, unfortunately, because CI adds commits on
> top. See the links to github I shared above for exact revisions.
>
>>
>>>> [ 343.220844] Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
>>>> [ 343.221436] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX,
>>>> 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
>>>> [ 343.222356] Workqueue: mld mld_dad_work
>>>> [ 343.222730] RIP: 0010:veth_xdp_rcv.constprop.0+0x6b/0x380
>>>>
>>>
>>> Can you give me the output from below command (on your compiled kernel):
>>>
>>> ./scripts/faddr2line drivers/net/veth.o veth_xdp_rcv.constprop.0+0x6b
>>>
>>
>> Still need above data/info please.
>
> root@...vm7589:/ci/workspace# ./scripts/faddr2line
> ./kout.gcc/drivers/net/veth.o veth_xdp_rcv.constprop.0+0x6b
> veth_xdp_rcv.constprop.0+0x6b/0x390:
> netdev_get_tx_queue at
> /ci/workspace/kout.gcc/../include/linux/netdevice.h:2637
> (inlined by) veth_xdp_rcv at
> /ci/workspace/kout.gcc/../drivers/net/veth.c:912
>
> Which is:
>
> veth.c:912
> struct veth_priv *priv = netdev_priv(rq->dev);
> int queue_idx = rq->xdp_rxq.queue_index;
> struct netdev_queue *peer_txq;
> struct net_device *peer_dev;
> int i, done = 0, n_xdpf = 0;
> void *xdpf[VETH_XDP_BATCH];
>
> /* NAPI functions as RCU section */
> peer_dev = rcu_dereference_check(priv->peer, rcu_read_lock_bh_held());
> ---> peer_txq = netdev_get_tx_queue(peer_dev, queue_idx);
>
> netdevice.h:2637
> static inline
> struct netdev_queue *netdev_get_tx_queue(const struct net_device *dev,
> unsigned int index)
> {
> DEBUG_NET_WARN_ON_ONCE(index >= dev->num_tx_queues);
> ---> return &dev->_tx[index];
> }
>
> So the suspect is peer_dev (priv->peer)?
Yes, this is the problem!
So, it seems that peer_dev (priv->peer) can become a NULL pointer.
Managed to reproduce - via manually deleting the peer device:
- ip link delete dev veth42
- while overloading veth41 via XDP redirecting packets into it.
Managed to trigger concurrent crashes on two CPUs (C0 + C3)
- so below output gets interlaced a bit:
[26700.481334][ C0] BUG: kernel NULL pointer dereference, address:
0000000000000438
[26700.489097][ C0] #PF: supervisor read access in kernel mode
[26700.495008][ C0] #PF: error_code(0x0000) - not-present page
[26700.500920][ C0] PGD 0 P4D 0
[26700.504233][ C0] Oops: Oops: 0000 [#1] SMP PTI
[26700.509023][ C0] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G
O N 6.15.0-bpf-next+ #40 PREEMPT(full)
[26700.520173][ C0] Tainted: [O]=OOT_MODULE, [N]=TEST
[26700.525305][ C0] Hardware name: Supermicro Super Server/X10SRi-F,
BIOS 2.0a 08/01/2016
[26700.533582][ C0] RIP: 0010:veth_xdp_rcv.constprop.0+0x37/0x2c0
[26700.539766][ C0] Code: 55 41 89 f5 41 54 55 53 48 89 fb 48 81 ec
90 00 00 00 8b 87 48 03 00 00 48 89 14 24 48 8b 97 f8 01 00 00 48 8b 92
c0 09 00 00 <3b> 82 38 04 00 00 0f 83 6d 02 00 00 4c 8d 3c 80 49 c1 e7
06 4c 03
[26700.559359][ C0] RSP: 0000:ffffc90000003cb0 EFLAGS: 00010282
[26700.565367][ C0] RAX: 0000000000000000 RBX: ffff888160e5c000 RCX:
ffffc90000003d78
[26700.573300][ C0] RDX: 0000000000000000 RSI: 0000000000000040 RDI:
ffff888160e5c000
[26700.581233][ C0] RBP: 0000000000000000 R08: 0000000000000000 R09:
0000000000000101
[26700.589161][ C0] R10: ffffffff830080c0 R11: 0000000000000000 R12:
0000000000000040
[26700.597092][ C0] R13: 0000000000000040 R14: ffffc90000003d78 R15:
ffff88887fc2d400
[26700.605022][ C0] FS: 0000000000000000(0000)
GS:ffff8888fbe16000(0000) knlGS:0000000000000000
[26700.613909][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[26700.620437][ C0] CR2: 0000000000000438 CR3: 000000010466c003 CR4:
00000000003726f0
[26700.628370][ C0] DR0: ffffffff83f801a4 DR1: ffffffff83f801a5 DR2:
ffffffff83f801a2
[26700.636301][ C0] DR3: ffffffff83f801a3 DR6: 00000000fffe0ff0 DR7:
0000000000000600
[26700.644232][ C0] Call Trace:
[26700.647453][ C0] <IRQ>
[26700.650243][ C0] ?
bpf_prog_4666c41a92ffb35e_tp_xdp_devmap_xmit_multi+0x129/0x1aa
[26700.658177][ C0] ? bpf_trace_run5+0x78/0xe0
[26700.662788][ C0] veth_poll+0x62/0x210
[26700.666878][ C0] ? mlx5e_napi_poll+0x35c/0x710 [mlx5_core]
[26700.672887][ C0] __napi_poll+0x2b/0x1f0
[26700.677155][ C0] net_rx_action+0x352/0x400
[26700.681682][ C0] handle_softirqs+0xe6/0x2d0
[26700.686300][ C0] irq_exit_rcu+0x9d/0xc0
[26700.690565][ C0] common_interrupt+0x81/0xa0
[26700.695183][ C0] </IRQ>
[26700.698056][ C0] <TASK>
[26700.700936][ C0] asm_common_interrupt+0x22/0x40
[26700.705898][ C0] RIP: 0010:cpuidle_enter_state+0xc2/0x430
[26700.711643][ C0] Code: 00 e8 02 99 35 ff e8 8d f8 ff ff 8b 53 04
49 89 c5 0f 1f 44 00 00 31 ff e8 4b 0c 34 ff 45 84 ff 0f 85 49 02 00 00
fb 45 85 f6 <0f> 88 8a 01 00 00 49 63 ce 4c 8b 14 24 48 8d 04 49 48 8d
14 81 48
[26700.731229][ C0] RSP: 0000:ffffffff83003e48 EFLAGS: 00000202
[26700.737229][ C0] RAX: ffff8888fbe16000 RBX: ffff88887fc347c0 RCX:
000000000000001f
[26700.745165][ C0] RDX: 0000000000000000 RSI: 00000000238e3e11 RDI:
0000000000000000
[26700.753095][ C0] RBP: 0000000000000002 R08: 0000000000000002 R09:
0000000000000006
[26700.761025][ C0] R10: 00000000ffffffff R11: 0000000000000000 R12:
ffffffff83350c40
[26700.768956][ C0] R13: 00001848b0b34003 R14: 0000000000000002 R15:
0000000000000000
[26700.776885][ C0] ? cpuidle_enter_state+0xb5/0x430
[26700.782019][ C0] cpuidle_enter+0x29/0x40
[26700.786375][ C0] do_idle+0x171/0x1d0
[26700.790378][ C0] cpu_startup_entry+0x25/0x30
[26700.795076][ C0] rest_init+0xcc/0xd0
[26700.799081][ C0] start_kernel+0x379/0x5b0
[26700.803520][ C0] x86_64_start_reservations+0x14/0x30
[26700.808910][ C0] x86_64_start_kernel+0xcb/0xd0
[26700.813782][ C0] common_startup_64+0x13e/0x148
[26700.818662][ C0] </TASK>
[26700.821628][ C0] Modules linked in: iptable_filter ip_tables
x_tables nf_defrag_ipv6 nf_defrag_ipv4 rpcrdma rdma_ucm ib_umad ib_ipoib
rdma_cm iw_cm ib_cm mlx5_ib macsec ib_uverbs ib_core mlx5_core sunrpc
intel_uncore_frequency intel_uncore_frequency_common coretemp i40e ixgbe
bnxt_en igb i2c_i801 igc rapl intel_cstate mei_me psample mdio libie
i2c_smbus acpi_ipmi ptp intel_uncore pcspkr mei i2c_algo_bit pps_core
wmi ipmi_si ipmi_devintf ipmi_msghandler acpi_pad bfq sch_fq_codel drm
i2c_core dm_multipath nfnetlink zram 842_decompress lz4hc_compress
842_compress zstd_compress hid_generic scsi_dh_rdac fuse [last unloaded:
nf_conntrack]
[26700.878187][ C0] CR2: 0000000000000438
[26700.882282][ C0] ---[ end trace 0000000000000000 ]---
[26700.882283][ C3] BUG: kernel NULL pointer dereference, address:
0000000000000438
[26700.890195][ C0] pstore: backend (erst) writing error (-28)
[26700.895228][ C3] #PF: supervisor read access in kernel mode
[26700.901054][ C0] RIP: 0010:veth_xdp_rcv.constprop.0+0x37/0x2c0
[26700.906877][ C3] #PF: error_code(0x0000) - not-present page
[26700.912960][ C0] Code: 55 41 89 f5 41 54 55 53 48 89 fb 48 81 ec
90 00 00 00 8b 87 48 03 00 00 48 89 14 24 48 8b 97 f8 01 00 00 48 8b 92
c0 09 00 00 <3b> 82 38 04 00 00 0f 83 6d 02 00 00 4c 8d 3c 80 49 c1 e7
06 4c 03
[26700.918786][ C3] PGD 0
[26700.938217][ C0] RSP: 0000:ffffc90000003cb0 EFLAGS: 00010282
[26700.938308][ C3] P4D 0
[26700.941016][ C0]
[26700.946927][ C3]
[26700.949629][ C0] RAX: 0000000000000000 RBX: ffff888160e5c000 RCX:
ffffc90000003d78
[26700.951815][ C3] Oops: Oops: 0000 [#2] SMP PTI
[26700.953997][ C0] RDX: 0000000000000000 RSI: 0000000000000040 RDI:
ffff888160e5c000
[26700.961816][ C3] CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Tainted: G
D O N 6.15.0-bpf-next+ #40 PREEMPT(full)
[26700.966513][ C0] RBP: 0000000000000000 R08: 0000000000000000 R09:
0000000000000101
[26700.974331][ C3] Tainted: [D]=DIE, [O]=OOT_MODULE, [N]=TEST
[26700.985356][ C0] R10: ffffffff830080c0 R11: 0000000000000000 R12:
0000000000000040
[26700.993173][ C3] Hardware name: Supermicro Super Server/X10SRi-F,
BIOS 2.0a 08/01/2016
[26700.998995][ C0] R13: 0000000000000040 R14: ffffc90000003d78 R15:
ffff88887fc2d400
[26701.006813][ C3] RIP: 0010:veth_xdp_rcv.constprop.0+0x37/0x2c0
[26701.014977][ C0] FS: 0000000000000000(0000)
GS:ffff8888fbe16000(0000) knlGS:0000000000000000
[26701.022796][ C3] Code: 55 41 89 f5 41 54 55 53 48 89 fb 48 81 ec
90 00 00 00 8b 87 48 03 00 00 48 89 14 24 48 8b 97 f8 01 00 00 48 8b 92
c0 09 00 00 <3b> 82 38 04 00 00 0f 83 6d 02 00 00 4c 8d 3c 80 49 c1 e7
06 4c 03
[26701.028879][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[26701.037650][ C3] RSP: 0018:ffffc900001accb0 EFLAGS: 00010282
[26701.057082][ C0] CR2: 0000000000000438 CR3: 000000010466c003 CR4:
00000000003726f0
[26701.063511][ C3]
[26701.069423][ C0] DR0: ffffffff83f801a4 DR1: ffffffff83f801a5 DR2:
ffffffff83f801a2
[26701.077241][ C3] RAX: 0000000000000003 RBX: ffff888160e5cb40 RCX:
ffffc900001acd78
[26701.079423][ C0] DR3: ffffffff83f801a3 DR6: 00000000fffe0ff0 DR7:
0000000000000600
[26701.087242][ C3] RDX: 0000000000000000 RSI: 0000000000000040 RDI:
ffff888160e5cb40
[26701.095059][ C0] Kernel panic - not syncing: Fatal exception in
interrupt
[26702.123660][ C0] Shutting down cpus with NMI
[26702.138666][ C0] Kernel Offset: disabled
[26702.145524][ C0] ---[ end Kernel panic - not syncing: Fatal
exception in interrupt ]---
>>
>>>> [...] >>>>
>>>>> @@ -925,6 +959,9 @@ static int veth_xdp_rcv(struct veth_rq *rq, int
>>>>> budget,
>>>>> rq->stats.vs.xdp_packets += done;
>>>>> u64_stats_update_end(&rq->stats.syncp);
>>>>> + if (unlikely(netif_tx_queue_stopped(peer_txq)))
>>>>> + netif_tx_wake_queue(peer_txq);
>>>>> +
>>>>> return done;
>>>>> }
A fix could look like this:
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index e58a0f1b5c5b..a3046142cb8e 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -909,7 +909,7 @@ static int veth_xdp_rcv(struct veth_rq *rq, int budget,
/* NAPI functions as RCU section */
peer_dev = rcu_dereference_check(priv->peer,
rcu_read_lock_bh_held());
- peer_txq = netdev_get_tx_queue(peer_dev, queue_idx);
+ peer_txq = peer_dev ? netdev_get_tx_queue(peer_dev, queue_idx) :
NULL;
for (i = 0; i < budget; i++) {
void *ptr = __ptr_ring_consume(&rq->xdp_ring);
@@ -959,7 +959,7 @@ static int veth_xdp_rcv(struct veth_rq *rq, int budget,
rq->stats.vs.xdp_packets += done;
u64_stats_update_end(&rq->stats.syncp);
- if (unlikely(netif_tx_queue_stopped(peer_txq)))
+ if (peer_txq && unlikely(netif_tx_queue_stopped(peer_txq)))
netif_tx_wake_queue(peer_txq);
--Jesper
Powered by blists - more mailing lists