From: Mahe Tardy <mahe.tardy@gmail.com>
To: Emil Tsalapatis <emil@etsalapatis.com>
Cc: bpf@vger.kernel.org, andrii@kernel.org, ast@kernel.org,
daniel@iogearbox.net, edumazet@google.com,
john.fastabend@gmail.com, jordan@jrife.io, kuba@kernel.org,
martin.lau@linux.dev, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, pabeni@redhat.com,
yonghong.song@linux.dev
Subject: Re: [PATCH bpf-next v8 3/7] bpf: add bpf_icmp_send kfunc
Date: Wed, 24 Jun 2026 11:59:00 +0200 [thread overview]
Message-ID: <ajuqZMzqACLOijoC@gmail.com> (raw)
In-Reply-To: <DJGWWQQD3B0P.2O1D9MO17YRK4@etsalapatis.com>
On Tue, Jun 23, 2026 at 10:09:20PM -0400, Emil Tsalapatis wrote:
> On Mon Jun 22, 2026 at 8:05 AM EDT, Mahe Tardy wrote:
[...]
> > +#if IS_ENABLED(CONFIG_IPV6)
> > + case htons(ETH_P_IPV6):
> > + if (type != ICMPV6_DEST_UNREACH)
> > + return -EOPNOTSUPP;
> > + if (code < 0 || code > ICMPV6_REJECT_ROUTE)
> > + return -EINVAL;
> > +
> > + nskb = skb_clone(skb, GFP_ATOMIC);
> > + if (!nskb)
> > + return -ENOMEM;
> > +
> > + if (!pskb_network_may_pull(nskb, sizeof(struct ipv6hdr))) {
>
> Minor nit, but this may also fail with SKB_DROP_REASON_NOMEM. Now this is only
> possible if the IP header is not in the linear space which may well be
> impossible (?), but do we want to differentiate with
> pskb_network_may_pull_reason()?
Indeed, I think for the IP header is should be fine, but I replaced it
with the reason variant. Thanks!
> > + kfree_skb(nskb);
> > + return -EBADMSG;
> > + }
> > +
[...]
> > static int __init bpf_kfunc_init(void)
> > {
> > int ret;
> > @@ -12639,6 +12745,9 @@ static int __init bpf_kfunc_init(void)
> > ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
> > &bpf_kfunc_set_sock_addr);
> > ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_CLS, &bpf_kfunc_set_tcp_reqsk);
> > + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SKB, &bpf_kfunc_set_icmp_send);
> > + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_CLS, &bpf_kfunc_set_icmp_send);
> > + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_ACT, &bpf_kfunc_set_icmp_send);
>
> Based on Sashiko's feedback, since we mostly care about cgroup_skb
> should we just make it exclusive to them and drop CLS_ACT?
This would indeed simplify this patchset, I could drop most of the
complication induced by tc ingress routing. But I think having both
cgroup_skb and tc support would be nice as a first implem. I'll try
again in a new version as I added a test for ingress tc and could
actually fix the routing based on sashiko's feedback (this also drop the
first two patches that were partially wrong).
> > return ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SOCK_OPS, &bpf_kfunc_set_sock_ops);
> > }
> > late_initcall(bpf_kfunc_init);
> > --
> > 2.34.1
>
next prev parent reply other threads:[~2026-06-24 9:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 12:05 [PATCH bpf-next v8 0/7] bpf: add icmp_send kfunc Mahe Tardy
2026-06-22 12:05 ` [PATCH bpf-next v8 1/7] net: move netfilter nf_reject_fill_skb_dst to core ipv4 Mahe Tardy
2026-06-24 0:09 ` Emil Tsalapatis
2026-06-22 12:05 ` [PATCH bpf-next v8 2/7] net: move netfilter nf_reject6_fill_skb_dst to core ipv6 Mahe Tardy
2026-06-24 0:16 ` Emil Tsalapatis
2026-06-22 12:05 ` [PATCH bpf-next v8 3/7] bpf: add bpf_icmp_send kfunc Mahe Tardy
2026-06-22 12:32 ` sashiko-bot
2026-06-22 18:55 ` Mahe Tardy
2026-06-24 2:09 ` Emil Tsalapatis
2026-06-24 9:59 ` Mahe Tardy [this message]
2026-06-24 11:45 ` Mahe Tardy
2026-06-22 12:05 ` [PATCH bpf-next v8 4/7] selftests/bpf: add bpf_icmp_send kfunc cgroup_skb tests Mahe Tardy
2026-06-22 12:41 ` bot+bpf-ci
2026-06-24 7:26 ` Emil Tsalapatis
2026-06-22 12:05 ` [PATCH bpf-next v8 5/7] selftests/bpf: add bpf_icmp_send kfunc cgroup_skb IPv6 tests Mahe Tardy
2026-06-22 12:15 ` sashiko-bot
2026-06-22 12:05 ` [PATCH bpf-next v8 6/7] selftests/bpf: add bpf_icmp_send kfunc tc tests Mahe Tardy
2026-06-22 12:41 ` bot+bpf-ci
2026-06-22 12:05 ` [PATCH bpf-next v8 7/7] selftests/bpf: add bpf_icmp_send recursion test Mahe Tardy
2026-06-22 12:13 ` sashiko-bot
2026-06-24 7:31 ` Emil Tsalapatis
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=ajuqZMzqACLOijoC@gmail.com \
--to=mahe.tardy@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=edumazet@google.com \
--cc=emil@etsalapatis.com \
--cc=john.fastabend@gmail.com \
--cc=jordan@jrife.io \
--cc=kuba@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=yonghong.song@linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.