From: Amery Hung <ameryhung@gmail.com>
To: Kui-Feng Lee <thinker.li@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, martin.lau@linux.dev,
song@kernel.org, kernel-team@meta.com, andrii@kernel.org,
sinquersw@gmail.com, kuifeng@meta.com
Subject: Re: [PATCH bpf-next v3 6/7] selftests/bpf: detach a struct_ops link from the subsystem managing it.
Date: Tue, 21 May 2024 22:56:26 +0000 [thread overview]
Message-ID: <20240521225252.GA3845630@bytedance> (raw)
In-Reply-To: <20240510002942.1253354-7-thinker.li@gmail.com>
On Thu, May 09, 2024 at 05:29:41PM -0700, Kui-Feng Lee wrote:
> Not only a user space program can detach a struct_ops link, the subsystem
> managing a link can also detach the link. This patch adds a kfunc to
> simulate detaching a link by the subsystem managing it and makes sure user
> space programs get notified through epoll.
>
> Signed-off-by: Kui-Feng Lee <thinker.li@gmail.com>
> ---
> .../selftests/bpf/bpf_testmod/bpf_testmod.c | 42 ++++++++++++
> .../bpf/bpf_testmod/bpf_testmod_kfunc.h | 1 +
> .../bpf/prog_tests/test_struct_ops_module.c | 67 +++++++++++++++++++
> .../selftests/bpf/progs/struct_ops_detach.c | 7 ++
> 4 files changed, 117 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> index 1150e758e630..1f347eed6c18 100644
> --- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> +++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c
> @@ -741,6 +741,38 @@ __bpf_kfunc int bpf_kfunc_call_kernel_getpeername(struct addr_args *args)
> return err;
> }
>
> +static DEFINE_SPINLOCK(detach_lock);
> +static struct bpf_link *link_to_detach;
> +
> +__bpf_kfunc int bpf_dummy_do_link_detach(void)
> +{
> + struct bpf_link *link;
> + int ret = -ENOENT;
> +
> + /* A subsystem must ensure that a link is valid when detaching the
> + * link. In order to achieve that, the subsystem may need to obtain
> + * a lock to safeguard a table that holds the pointer to the link
> + * being detached. However, the subsystem cannot invoke
> + * link->ops->detach() while holding the lock because other tasks
> + * may be in the process of unregistering, which could lead to
> + * acquiring the same lock and causing a deadlock. This is why
> + * bpf_link_inc_not_zero() is used to maintain the link's validity.
> + */
> + spin_lock(&detach_lock);
> + link = link_to_detach;
> + /* Make sure the link is still valid by increasing its refcnt */
> + if (link && IS_ERR(bpf_link_inc_not_zero(link)))
> + link = NULL;
> + spin_unlock(&detach_lock);
> +
I know it probably doesn't matter in this example, but where would you set
link_to_detach to NULL if reg and unreg can be called multiple times?
> + if (link) {
> + ret = link->ops->detach(link);
> + bpf_link_put(link);
> + }
> +
> + return ret;
> +}
[...]
next prev parent reply other threads:[~2024-05-21 22:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 0:29 [PATCH bpf-next v3 0/7] Notify user space when a struct_ops object is detached/unregistered Kui-Feng Lee
2024-05-10 0:29 ` [PATCH bpf-next v3 1/7] bpf: pass bpf_struct_ops_link to callbacks in bpf_struct_ops Kui-Feng Lee
2024-05-10 0:29 ` [PATCH bpf-next v3 2/7] bpf: enable detaching links of struct_ops objects Kui-Feng Lee
2024-05-21 1:22 ` Martin KaFai Lau
2024-05-21 7:30 ` Kui-Feng Lee
2024-05-21 18:09 ` Martin KaFai Lau
2024-05-10 0:29 ` [PATCH bpf-next v3 3/7] bpf: support epoll from bpf struct_ops links Kui-Feng Lee
2024-05-21 1:26 ` Martin KaFai Lau
2024-05-21 7:31 ` Kui-Feng Lee
2024-05-10 0:29 ` [PATCH bpf-next v3 4/7] bpf: export bpf_link_inc_not_zero Kui-Feng Lee
2024-05-10 0:29 ` [PATCH bpf-next v3 5/7] selftests/bpf: test struct_ops with epoll Kui-Feng Lee
2024-05-10 0:29 ` [PATCH bpf-next v3 6/7] selftests/bpf: detach a struct_ops link from the subsystem managing it Kui-Feng Lee
2024-05-21 22:56 ` Amery Hung [this message]
2024-05-22 0:31 ` Kui-Feng Lee
2024-05-22 17:33 ` Amery Hung
2024-05-10 0:29 ` [PATCH bpf-next v3 7/7] selftests/bpf: make sure bpf_testmod handling racing link destroying well Kui-Feng Lee
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=20240521225252.GA3845630@bytedance \
--to=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=kernel-team@meta.com \
--cc=kuifeng@meta.com \
--cc=martin.lau@linux.dev \
--cc=sinquersw@gmail.com \
--cc=song@kernel.org \
--cc=thinker.li@gmail.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.