From: Martin KaFai Lau <martin.lau@linux.dev>
To: Eyal Birger <eyal.birger@gmail.com>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kselftest@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
steffen.klassert@secunet.com, herbert@gondor.apana.org.au,
andrii@kernel.org, daniel@iogearbox.net,
nicolas.dichtel@6wind.com, razor@blackwall.org, mykolal@fb.com,
ast@kernel.org, song@kernel.org, yhs@fb.com,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
haoluo@google.com, jolsa@kernel.org, shuah@kernel.org
Subject: Re: [PATCH ipsec-next,v2 2/3] xfrm: interface: Add unstable helpers for setting/getting XFRM metadata from TC-BPF
Date: Wed, 30 Nov 2022 10:14:56 -0800 [thread overview]
Message-ID: <b3306950-bea9-e914-0491-54048d6d55e4@linux.dev> (raw)
In-Reply-To: <20221129132018.985887-3-eyal.birger@gmail.com>
On 11/29/22 5:20 AM, Eyal Birger wrote:
> diff --git a/net/xfrm/xfrm_interface_bpf.c b/net/xfrm/xfrm_interface_bpf.c
> new file mode 100644
> index 000000000000..757e15857dbf
> --- /dev/null
> +++ b/net/xfrm/xfrm_interface_bpf.c
> @@ -0,0 +1,100 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* Unstable XFRM Helpers for TC-BPF hook
> + *
> + * These are called from SCHED_CLS BPF programs. Note that it is
> + * allowed to break compatibility for these functions since the interface they
> + * are exposed through to BPF programs is explicitly unstable.
> + */
> +
> +#include <linux/bpf.h>
> +#include <linux/btf_ids.h>
> +
> +#include <net/dst_metadata.h>
> +#include <net/xfrm.h>
> +
> +struct bpf_xfrm_info {
No need to introduce a bpf variant of the "struct xfrm_md_info" (more on this
later).
> + u32 if_id;
> + int link;
> +};
> +
> +static struct metadata_dst __percpu *xfrm_md_dst;
> +__diag_push();
> +__diag_ignore_all("-Wmissing-prototypes",
> + "Global functions as their definitions will be in xfrm_interface BTF");
> +
> +__used noinline
> +int bpf_skb_get_xfrm_info(struct __sk_buff *skb_ctx, struct bpf_xfrm_info *to)
This kfunc is not needed. It only reads the skb->_skb_refdst. The new kfunc
bpf_rdonly_cast() can be used. Take a look at the bpf_rdonly_cast() usages in
the selftests/bpf/progs/type_cast.c. It was in bpf-next only but should also be
in net-next now.
> +{
> + struct sk_buff *skb = (struct sk_buff *)skb_ctx;
> + struct xfrm_md_info *info;
> +
> + memset(to, 0, sizeof(*to));
> +
> + info = skb_xfrm_md_info(skb);
> + if (!info)
> + return -EINVAL;
> +
> + to->if_id = info->if_id;
> + to->link = info->link;
> + return 0;
> +}
> +
> +__used noinline
> +int bpf_skb_set_xfrm_info(struct __sk_buff *skb_ctx,
> + const struct bpf_xfrm_info *from)
Directly use "const struct xfrm_md_info *from" instead. This kfunc can check
from->dst_orig != NULL and return -EINVAL. It will then have a consistent API
with the bpf_rdonly_cast() mentioned above.
> +{
> + struct sk_buff *skb = (struct sk_buff *)skb_ctx;
> + struct metadata_dst *md_dst;
> + struct xfrm_md_info *info;
> +
> + if (unlikely(skb_metadata_dst(skb)))
> + return -EINVAL;
> +
> + md_dst = this_cpu_ptr(xfrm_md_dst);
> +
> + info = &md_dst->u.xfrm_info;
> + memset(info, 0, sizeof(*info));
Unnecessary memset here. Everything should have been initialized below.
bpf_skb_set_tunnel_key() needs memset but not here.
> +
> + info->if_id = from->if_id;
> + info->link = from->link;
> + skb_dst_force(skb);
> + info->dst_orig = skb_dst(skb);
> +
> + dst_hold((struct dst_entry *)md_dst);
> + skb_dst_set(skb, (struct dst_entry *)md_dst);
> + return 0;
> +}
> +
> +__diag_pop()
> +
> +BTF_SET8_START(xfrm_ifc_kfunc_set)
> +BTF_ID_FLAGS(func, bpf_skb_get_xfrm_info)
> +BTF_ID_FLAGS(func, bpf_skb_set_xfrm_info)
> +BTF_SET8_END(xfrm_ifc_kfunc_set)
> +
> +static const struct btf_kfunc_id_set xfrm_interface_kfunc_set = {
> + .owner = THIS_MODULE,
> + .set = &xfrm_ifc_kfunc_set,
> +};
> +
> +int __init register_xfrm_interface_bpf(void)
> +{
> + int err;
> +
> + xfrm_md_dst = metadata_dst_alloc_percpu(0, METADATA_XFRM,
> + GFP_KERNEL);
May be DEFINE_PER_CPU() instead?
> + if (!xfrm_md_dst)
> + return -ENOMEM;
> + err = register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_CLS,
> + &xfrm_interface_kfunc_set);
> + if (err < 0) {
> + cleanup_xfrm_interface_bpf();
> + return err;
> + }
> + return 0;
> +}
> +
> +void __exit cleanup_xfrm_interface_bpf(void)
> +{
> + metadata_dst_free_percpu(xfrm_md_dst);
> +}
next prev parent reply other threads:[~2022-11-30 18:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-29 13:20 [PATCH ipsec-next,v2 0/3] xfrm: interface: Add unstable helpers for XFRM metadata Eyal Birger
2022-11-29 13:20 ` [PATCH ipsec-next,v2 1/3] xfrm: interface: rename xfrm_interface.c to xfrm_interface_core.c Eyal Birger
2022-11-29 13:20 ` [PATCH ipsec-next,v2 2/3] xfrm: interface: Add unstable helpers for setting/getting XFRM metadata from TC-BPF Eyal Birger
2022-11-30 18:14 ` Martin KaFai Lau [this message]
2022-12-01 5:55 ` Eyal Birger
2022-12-01 13:30 ` Eyal Birger
2022-12-01 20:18 ` Martin KaFai Lau
2022-12-01 20:47 ` Eyal Birger
2022-12-01 20:21 ` Martin KaFai Lau
2022-11-29 13:20 ` [PATCH ipsec-next,v2 3/3] selftests/bpf: add xfrm_info tests Eyal Birger
2022-11-30 18:41 ` Martin KaFai Lau
2022-11-30 18:48 ` Martin KaFai Lau
2022-12-01 5:34 ` Eyal Birger
2022-12-01 7:33 ` Martin KaFai Lau
2022-12-01 13:33 ` Eyal Birger
2022-12-01 20:26 ` Martin KaFai Lau
2022-12-01 20:48 ` Eyal Birger
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=b3306950-bea9-e914-0491-54048d6d55e4@linux.dev \
--to=martin.lau@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=eyal.birger@gmail.com \
--cc=haoluo@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mykolal@fb.com \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=sdf@google.com \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=steffen.klassert@secunet.com \
--cc=yhs@fb.com \
/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.