From: Martin KaFai Lau <martin.lau@linux.dev>
To: Amery Hung <ameryhung@gmail.com>
Cc: bpf@vger.kernel.org, daniel@iogearbox.net, andrii@kernel.org,
alexei.starovoitov@gmail.com, martin.lau@kernel.org,
eddyz87@gmail.com, kernel-team@meta.com
Subject: Re: [PATCH bpf-next v1 0/5] Extend struct_ops support for operators
Date: Fri, 14 Feb 2025 18:09:08 -0800 [thread overview]
Message-ID: <45dd4b34-e8e0-47d0-a91a-9d2c6d3196a7@linux.dev> (raw)
In-Reply-To: <20250214164520.1001211-1-ameryhung@gmail.com>
On 2/14/25 8:45 AM, Amery Hung wrote:
> Hi,
>
> I am splitting the bpf qdisc patchset into smaller landable sets and
> this is the first part.
>
> This patchset supports struct_ops operators that acquire kptrs through
> arguments and operators that return a kptr. A coming new struct_ops use
> case, bpf qdisc [0], has two operators that are not yet supported by
> current struct_ops infrastructure. Qdisc_ops::enqueue requires getting
> referenced skb kptr from the argument; Qdisc_ops::dequeue needs to return
> a referenced skb kptr. This patchset will allow bpf qdisc and other
> potential struct_ops implementers to do so.
>
> For struct_ops implementers:
>
> - To get a kptr from an argument, a struct_ops implementer needs to
> annotate the argument name in the stub function with "__ref" suffix.
>
> - The kptr return will automatically work as we now allow operators that
> return a struct pointer.
>
> - The verifier allows returning a null pointer. More control can be
> added later if there is a future struct_ops implementer only expecting
> valid pointers.
>
> For struct_ops users:
>
> - The referenced kptr acquired through the argument needs to be released
> or xchged into maps just like ones acquired via kfuncs.
>
> - To return a referenced kptr in struct_ops,
> 1) The type of the pointer must matches the return type
> 2) The pointer must comes from the kernel (not locally allocated), and
> 3) The pointer must be in its unmodified form
I only left some minor comments in the patches.
A few other thoughts:
I think https://lore.kernel.org/bpf/20250210174336.2024258-11-ameryhung@gmail.com/
should be a good addition also. A new subtest in the prog_tests/pro_epilogue.c
should do for testing it.
Another thing is disabling tail call in the bpf_qdisc_get_func_proto in
https://lore.kernel.org/bpf/20250210174336.2024258-9-ameryhung@gmail.com/
I am wondering if it can be done in a generic way for all struct_ops in
check_struct_ops_btf_id(). At that point, we should know all the "has_tail_call".
I meant only for ops with __ref arg such that it won't break the existing
struct_ops.
I think both of them could be a followup.
next prev parent reply other threads:[~2025-02-15 2:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-14 16:45 [PATCH bpf-next v1 0/5] Extend struct_ops support for operators Amery Hung
2025-02-14 16:45 ` [PATCH bpf-next v1 1/5] bpf: Make every prog keep a copy of ctx_arg_info Amery Hung
2025-02-15 0:20 ` Martin KaFai Lau
2025-02-15 2:41 ` Alexei Starovoitov
2025-02-15 4:39 ` Amery Hung
2025-02-14 16:45 ` [PATCH bpf-next v1 2/5] bpf: Support getting referenced kptr from struct_ops argument Amery Hung
2025-02-15 0:49 ` Martin KaFai Lau
2025-02-15 2:48 ` Alexei Starovoitov
2025-02-15 4:58 ` Amery Hung
2025-02-14 16:45 ` [PATCH bpf-next v1 3/5] selftests/bpf: Test referenced kptr arguments of struct_ops programs Amery Hung
2025-02-15 1:14 ` Martin KaFai Lau
2025-02-15 4:30 ` Amery Hung
2025-02-14 16:45 ` [PATCH bpf-next v1 4/5] bpf: Allow struct_ops prog to return referenced kptr Amery Hung
2025-02-15 1:42 ` Martin KaFai Lau
2025-02-14 16:45 ` [PATCH bpf-next v1 5/5] selftests/bpf: Test returning referenced kptr from struct_ops programs Amery Hung
2025-02-15 1:52 ` Martin KaFai Lau
2025-02-15 2:09 ` Martin KaFai Lau [this message]
2025-02-18 22:20 ` [PATCH bpf-next v1 0/5] Extend struct_ops support for operators Amery Hung
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=45dd4b34-e8e0-47d0-a91a-9d2c6d3196a7@linux.dev \
--to=martin.lau@linux.dev \
--cc=alexei.starovoitov@gmail.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@meta.com \
--cc=martin.lau@kernel.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 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.