On 10/21/25 4:47 PM, Maciej Fijalkowski wrote:
On Tue, Oct 21, 2025 at 07:02:06PM +0800, Jason Xing wrote:
On Tue, Oct 21, 2025 at 5:31 AM mc36 <[email protected]> wrote:
hi,
On 10/20/25 11:04, Jason Xing wrote:
I followed your steps you attached in your code:
////// gcc xskInt.c -lxdp
////// sudo ip link add veth1 type veth
////// sudo ip link set veth0 up
////// sudo ip link set veth1 up
ip link set dev veth1 address 3a:10:5c:53:b3:5c
Great, it indeed helps me reproduce the issue, so I managed to see the
exact same stack. Let me dig into it more deeply.
splat comes from skb_orphan() calling skb->destructor() with ::cb field
being already taken by IP layer. A hotfix would simply be moving this call
before we memset cb in ip_rcv_core():
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 273578579a6b..db30645f8c35 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -535,14 +535,14 @@ static struct sk_buff *ip_rcv_core(struct sk_buff *skb,
struct net *net)
iph = ip_hdr(skb);
skb->transport_header = skb->network_header + iph->ihl*4;
- /* Remove any debris in the socket control block */
- memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
- IPCB(skb)->iif = skb->skb_iif;
-
/* Must drop socket now because of tproxy. */
if (!skb_sk_is_prefetched(skb))
skb_orphan(skb);
+ /* Remove any debris in the socket control block */
+ memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
+ IPCB(skb)->iif = skb->skb_iif;
+
return skb;
csum_error:
However, I do not understand why setting mac addr on one veth interface
triggers this path.
Ugh, sorry then. I just sent a patch to the list and didn't see your
email. Anyway, I believe it is safer to avoid using skb control block if
other subsystems might take control over it.
Feel free to discard my patch at:
https://lore.kernel.org/netdev/[email protected]/
Thanks,
Fernando.
Thanks,
Jason
