All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin KaFai Lau <martin.lau@linux.dev>
To: Kui-Feng Lee <sinquersw@gmail.com>, Kui-Feng Lee <thinker.li@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, song@kernel.org,
	kernel-team@meta.com, andrii@kernel.org, kuifeng@meta.com
Subject: Re: [PATCH bpf-next 6/6] selftests/bpf: test detaching struct_ops links.
Date: Fri, 3 May 2024 12:15:57 -0700	[thread overview]
Message-ID: <4f54cc5e-6864-4ff8-b840-1f93000cb7a7@linux.dev> (raw)
In-Reply-To: <4462086b-c01a-4733-8a15-7ef0d1f91c2f@gmail.com>

On 5/3/24 11:34 AM, Kui-Feng Lee wrote:
> 
> 
> On 5/2/24 11:15, Martin KaFai Lau wrote:
>> On 4/29/24 2:36 PM, Kui-Feng Lee wrote:
>>> @@ -572,6 +576,12 @@ static int bpf_dummy_reg(void *kdata)
>>>       if (ops->test_2)
>>>           ops->test_2(4, ops->data);
>>> +    if (ops->do_unreg) {
>>> +        rcu_read_lock();
>>> +        bpf_struct_ops_kvalue_unreg(kdata);
>>
>> Instead of unreg() immediately before the reg() has returned, the test should 
>> reflect more on how the subsystem can use it in practice. The subsystem does 
>> not do unreg() during reg().
>>
>> It also needs to test a case when the link is created and successfully 
>> registered to the subsystem. The user space does BPF_LINK_DETACH first and  >> then the subsystem does link->ops->detach() by itself later.

> 
> agree
> 
>>
>> It can create a kfunc in bpf_testmod.c to trigger the subsystem to do 
>> link->ops->detach(). The kfunc can be called by a SEC("syscall") bpf prog 
>> which is run by bpf_prog_test_run_opts(). The test_progs can then decide on 
>> the timing when to do link->ops->detach() to test different cases.
> 
> What is the purpose of this part?
> If it goes through link->ops->detach(), it should work just like to call
> bpf_link_detach() twice on the same link from the user space. Do you
> want to make sure detaching a link twice work?

It is not quite what I meant and apparently link detach twice on the same valid 
(i.e. refcnt non zero) link won't work.

Anyhow, the idea is to show how the racing case may work in patch 3 (when 
userspace tries to detach and the subsystem tries to detach/unreg itself also). 
I was suggesting the kfunc idea such that the test_progs can have better control 
on the timing on when to ask the subsystem to unreg/detach itself instead of 
having to do the unreg() during the reg() as in patch 6 here. If kfunc does not 
make sense and there is a better way to do this, feel free to ignore.


  reply	other threads:[~2024-05-03 19:16 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-29 21:36 [PATCH bpf-next 0/6] Notify user space when a struct_ops object is detached/unregisterd Kui-Feng Lee
2024-04-29 21:36 ` [PATCH bpf-next 1/6] bpf: add a pointer of the attached link to bpf_struct_ops_map Kui-Feng Lee
2024-05-01 17:01   ` Andrii Nakryiko
2024-05-01 22:15     ` Kui-Feng Lee
2024-04-29 21:36 ` [PATCH bpf-next 2/6] bpf: export bpf_link_inc_not_zero() Kui-Feng Lee
2024-04-29 21:36 ` [PATCH bpf-next 3/6] bpf: provide a function to unregister struct_ops objects from consumers Kui-Feng Lee
2024-05-01 18:48   ` Martin KaFai Lau
2024-05-01 22:15     ` Kui-Feng Lee
2024-05-01 23:06       ` Martin KaFai Lau
2024-05-02 17:56     ` Martin KaFai Lau
2024-05-02 18:29       ` Martin KaFai Lau
2024-05-03  0:41       ` Kui-Feng Lee
2024-05-03 16:19         ` Alexei Starovoitov
2024-05-03 18:09           ` Kui-Feng Lee
2024-05-03 17:17         ` Martin KaFai Lau
2024-04-29 21:36 ` [PATCH bpf-next 4/6] bpf: detach a bpf_struct_ops_map from a link Kui-Feng Lee
2024-04-29 21:36 ` [PATCH bpf-next 5/6] bpf: support epoll from bpf struct_ops links Kui-Feng Lee
2024-05-01 17:03   ` Andrii Nakryiko
2024-05-01 22:16     ` Kui-Feng Lee
2024-04-29 21:36 ` [PATCH bpf-next 6/6] selftests/bpf: test detaching " Kui-Feng Lee
2024-05-01 17:05   ` Andrii Nakryiko
2024-05-01 22:17     ` Kui-Feng Lee
2024-05-02 18:15   ` Martin KaFai Lau
2024-05-03 18:34     ` Kui-Feng Lee
2024-05-03 19:15       ` Martin KaFai Lau [this message]
2024-05-03 21:34         ` Kui-Feng Lee
2024-05-03 21:59           ` Martin KaFai Lau

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=4f54cc5e-6864-4ff8-b840-1f93000cb7a7@linux.dev \
    --to=martin.lau@linux.dev \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kuifeng@meta.com \
    --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.