[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAKKD2Pow_4GOB4qr9Ms4yiXaMjGX7NeGOKay+x6ohTurQGfLcw@mail.gmail.com>
Date: Sun, 30 Mar 2025 07:55:46 +0800
From: Xinyong Wang <wang.xy.chn@...il.com>
To: bpf@...r.kernel.org
Cc: netdev@...r.kernel.org
Subject: [BPF] Question about per-CPU metadata_dst in bpf helper
bpf_skb_set_tunnel_key implementation
Hi all,
I am an eBPF newbie and still learning the internals. when studying
the implementation of the bpf_skb_set_tunnel_key helper, I have a
question regarding its handling of race conditions.
>From what I understand, bpf_skb_set_tunnel_key uses a per-CPU variable
metadata_dst to set tunnel information for a packet. However, it
appears that the function directly references this per-CPU variable
md_dst without copying the tunnel information to the skb, just
refcounted. This may raise a concern about whether the tunnel
information could be overwritten by another packet before the original
packet is finally sent.
For example:
1. When packet A tx, it calls bpf_skb_set_tunnel_key, and the tunnel
information is stored in the per-CPU variable md_dst.
2. Packet A is queued into qdisc for transmission
3. Before packet A is sent, packet B arrives at the same CPU and calls
bpf_skb_set_tunnel_key, modifying tunnel info of the same per-CPU
variable md_dst.
4. When packet A is finally sent, it might use the tunnel information
set by packet B, leading to incorrect behavior.
Could someone clarify how the bpf_skb_set_tunnel_key ensures that the
tunnel information is not overwritten in such cases? why does the
example case above not occur?
Thank you for your time and expertise!
Best regards,
Xinyong
Powered by blists - more mailing lists