From: Martin KaFai Lau <martin.lau@linux.dev>
To: Mahe Tardy <mahe.tardy@gmail.com>
Cc: alexei.starovoitov@gmail.com, andrii@kernel.org, ast@kernel.org,
bpf@vger.kernel.org, coreteam@netfilter.org,
daniel@iogearbox.net, fw@strlen.de, john.fastabend@gmail.com,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
oe-kbuild-all@lists.linux.dev, pablo@netfilter.org,
lkp@intel.com
Subject: Re: [PATCH bpf-next v3 0/4] bpf: add icmp_send_unreach kfunc
Date: Tue, 29 Jul 2025 18:54:58 -0700 [thread overview]
Message-ID: <7083544f-5b0c-432e-bec8-509ca733f316@linux.dev> (raw)
In-Reply-To: <aIiaB2QUxKmhvPlx@gmail.com>
On 7/29/25 2:53 AM, Mahe Tardy wrote:
>> Which other program types do you need this kfunc to send icmp and the future
>> tcp rst?
>
> I don't really know, I mostly need this in cgroup_skb for my use case
> but I could see other programs type using this either for simplification
> (for progs that can already rewrite the packet, like tc) or other
> programs types like cgroup_skb, because they can't touch the packet
> themselves.
I also don't think the tc needs this kfunc either. The tc should already have
ways to do this now.
>
>>
>> This cover letter mentioned sending icmp unreach is easier than sending tcp
>> rst. What problems do you see in sending tcp rst?
>>
>
> Yes, I based these patches on what net/ipv4/netfilter/ipt_REJECT.c's
> 'reject_tg' function does. In the case of sending ICMP unreach
> 'nf_send_unreach', the routing step is quite straighforward as they are
> only inverting the daddr and the saddr (that's what my renamed/moved
> ip_route_reply_fetch_dst helper does).
>
> In the case of sending RST 'nf_send_reset', there are extra steps, first
> the same routing mechanism is done by just inverting the daddr and the
> saddr but later 'ip_route_me_harder' is called which is doing a lot
> more. I'm currently not sure which parts of this must be ported to work
> in our BPF use case so I wanted to start with unreach.
I don't think we necessarily need to completely borrow from nf, the hooks'
locations are different and the use case may be different.
A concern that I have is the icmp6_send called by the kfunc. The icmp6_send
should eventually call to ip6_finish_output which may call the very same
"cgroup/egress" program again in a recursive way. The same for v4 icmp_send.
The icmp packet is sent from an internal kernel sk. I suspect you will see this
recursive behavior if the test is done in the default cgroup (/sys/fs/cgroup). I
think the is_ineligible(skb) should have stopped the second icmpv6_send from
replying to an icmp error and the cgroup hook cannot change the skb. However, I
am not sure I want to cross this bridge. Is there a way to avoid the recursive
bpf prog?
next prev parent reply other threads:[~2025-07-30 1:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAADnVQKq_-=N7eJoup6AqFngoocT+D02NF0md_3mi2Vcrw09nQ@mail.gmail.com>
2025-07-25 18:53 ` [PATCH bpf-next v1 0/4] bpf: add icmp_send_unreach kfunc Mahe Tardy
2025-07-25 18:53 ` [PATCH bpf-next v2 1/4] net: move netfilter nf_reject_fill_skb_dst to core ipv4 Mahe Tardy
2025-07-25 18:53 ` [PATCH bpf-next v2 2/4] net: move netfilter nf_reject6_fill_skb_dst to core ipv6 Mahe Tardy
2025-07-25 18:53 ` [PATCH bpf-next v2 3/4] bpf: add bpf_icmp_send_unreach cgroup_skb kfunc Mahe Tardy
2025-07-27 1:49 ` kernel test robot
2025-07-28 9:43 ` [PATCH bpf-next v3 0/4] bpf: add icmp_send_unreach kfunc Mahe Tardy
2025-07-28 9:43 ` [PATCH bpf-next v3 1/4] net: move netfilter nf_reject_fill_skb_dst to core ipv4 Mahe Tardy
2025-07-28 9:43 ` [PATCH bpf-next v3 2/4] net: move netfilter nf_reject6_fill_skb_dst to core ipv6 Mahe Tardy
2025-07-28 9:43 ` [PATCH bpf-next v3 3/4] bpf: add bpf_icmp_send_unreach cgroup_skb kfunc Mahe Tardy
2025-07-28 20:10 ` kernel test robot
2025-07-29 1:05 ` Martin KaFai Lau
2025-07-29 10:06 ` Mahe Tardy
2025-07-29 23:13 ` Martin KaFai Lau
2025-07-28 9:43 ` [PATCH bpf-next v3 4/4] selftests/bpf: add icmp_send_unreach kfunc tests Mahe Tardy
2025-07-28 15:40 ` Yonghong Song
2025-07-28 15:59 ` Mahe Tardy
2025-07-29 1:18 ` Martin KaFai Lau
2025-07-29 9:09 ` Mahe Tardy
2025-07-29 23:27 ` Martin KaFai Lau
2025-07-30 0:01 ` Martin KaFai Lau
2025-07-30 0:32 ` Martin KaFai Lau
2025-08-05 23:26 ` Jordan Rife
2025-07-29 1:21 ` [PATCH bpf-next v3 0/4] bpf: add icmp_send_unreach kfunc Martin KaFai Lau
2025-07-29 9:53 ` Mahe Tardy
2025-07-30 1:54 ` Martin KaFai Lau [this message]
2025-08-01 18:50 ` Mahe Tardy
2025-07-25 18:53 ` [PATCH bpf-next v2 4/4] selftests/bpf: add icmp_send_unreach kfunc tests Mahe Tardy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7083544f-5b0c-432e-bec8-509ca733f316@linux.dev \
--to=martin.lau@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=coreteam@netfilter.org \
--cc=daniel@iogearbox.net \
--cc=fw@strlen.de \
--cc=john.fastabend@gmail.com \
--cc=lkp@intel.com \
--cc=mahe.tardy@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).