On 5/30/24 12:42 PM, Kuifeng Lee wrote:
On Thu, May 30, 2024 at 12:34 PM Kuifeng Lee <sinquersw@xxxxxxxxx> wrote:
On Thu, May 30, 2024 at 10:53 AM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote:
[ The mailing list got dropped in your reply, so CC back the list ]
On 5/29/24 11:05 PM, Kuifeng Lee wrote:
On Wed, May 29, 2024 at 2:51 PM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote:
On 5/24/24 3:30 PM, Kui-Feng Lee wrote:
@@ -832,11 +865,20 @@ static int bpf_dummy_reg(void *kdata, struct bpf_link *link)
if (ops->test_2)
ops->test_2(4, ops->data);
+ spin_lock(&detach_lock);
+ if (!link_to_detach)
+ link_to_detach = link;
bpf_testmod_ops is used in a few different tests now. Can you check if
"./test_progs -j <num_of_parallel_workers>" will work considering link_to_detach
here is the very first registered link.
Yes, it works. Since the test in test_struct_ops_modules.c is serial,
no other test will
be run simultaneously. And its subtests are run one after another.
just did a quick search on "bpf_map__attach_struct_ops", how about the other
tests like struct_ops_autocreate.c and test_struct_ops_multi_pages.c ?
Got it!
I will put all these test to serial. WDYT?
Other than slowing things down, the future new bpf_testmod_ops tests also need
to remember to serialize. It is not good.
Put a flag in "struct bpf_testmod_ops" to flag it is testing the detach test?
By the way, even without putting all these tests to serial, it still works.
The serial ones will be performed without other tests running at
the background. This test is the only test replying to the notification feature
so far.
The new detach test added in patch 6 here may work. How about other existing
tests? afaik, the link_to_detach here could be the link belonging to other
tests. I don't think those tests expect their link to be detached by the new
kfunc bpf_dummy_do_link_detach.
+ spin_unlock(&detach_lock);
+
return 0;
}
