Re: [PATCH bpf-next v4 3/3] selftests/bpf: Add task work scheduling race test

[luyun <luyun_611@163.com>]

在 2026/9/29 20:00, Mykyta Yatsenko 写道:
>
> On 9/29/26 9:12 AM, bot+bpf-ci@kernel.org wrote:
>>> selftests/bpf: Add task work scheduling race test
>>>
>>> Exercise task-work scheduling and callback execution on different CPUs
>>> while userspace reuses or deletes the associated map value.  Run 1500
>>> rounds rotating through context reuse, deletion after the callback has
>>> recorded its generation, and deletion racing with scheduling.
>>>
>>> Publish the scheduling result and its generation in one packed value, so
>>> userspace does not rely on ordering between separate map slots.  Record
>>> callbacks in separate per-generation slots so an earlier callback cannot
>>> satisfy a later round's completion check.
>>>
>>> Retry transient -EBUSY results while the context is unavailable for
>>> reuse.  In the deletion-race case, allow -ENOENT if the element is
>>> removed before a retry finds it.
>>>
>>> Choose two CPUs from the process affinity mask and skip if fewer than
>>> two are available.  Bound the thread-start wait, report thread creation
>>> and affinity failures, and stop the worker threads with an atomic
>>> handshake.
>>>
>>> Signed-off-by: Yun Lu <luyun@kylinos.cn>
>> This isn't a bug, but could the changelog say which of the preceding fixes
>> this test is meant to cover, and which interleaving each variant targets,
>> instead of listing implementation details like the bounded thread-start
>> wait and the atomic stop handshake?
>>
>>> diff --git a/tools/testing/selftests/bpf/prog_tests/test_task_work.c b/tools/testing/selftests/bpf/prog_tests/test_task_work.c
>>> --- a/tools/testing/selftests/bpf/prog_tests/test_task_work.c
>>> +++ b/tools/testing/selftests/bpf/prog_tests/test_task_work.c
>>> @@ -5,10 +5,14 @@
>>>   #include <stdio.h>
>>>   #include "task_work.skel.h"
>>>   #include "task_work_fail.skel.h"
>>> +#include "task_work_race.skel.h"
>>>   #include <linux/bpf.h>
>>>   #include <linux/perf_event.h>
>>>   #include <sys/syscall.h>
>>>   #include <time.h>
>>> +#include <pthread.h>
>>> +#include <sched.h>
>>> +#include <unistd.h>
>> [ ... ]
>>
>>> +static void *task_work_race_trigger(void *arg)
>>> +{
>>> +	struct task_work_race_ctx *ctx = arg;
>>> +	int err;
>>> +
>>> +	err = task_work_race_pin_cpu(ctx->trigger_cpu);
>>> +	if (err)
>>> +		__atomic_store_n(&ctx->setup_err, err, __ATOMIC_RELEASE);
>>> +	__atomic_store_n(&ctx->trigger_tid, syscall(__NR_gettid),
>>> +			 __ATOMIC_RELEASE);
>>> +	while (!__atomic_load_n(&ctx->stop, __ATOMIC_ACQUIRE))
>>> +		getppid();
>>> +	return NULL;
>>> +}
>>> +
>>> +static void *task_work_race_target(void *arg)
>>> +{
>>> +	struct task_work_race_ctx *ctx = arg;
>>> +	int err;
>>> +
>>> +	err = task_work_race_pin_cpu(ctx->target_cpu);
>>> +	if (err)
>>> +		__atomic_store_n(&ctx->setup_err, err, __ATOMIC_RELEASE);
>>> +	__atomic_store_n(&ctx->target_tid, syscall(__NR_gettid),
>>> +			 __ATOMIC_RELEASE);
>>> +	while (!__atomic_load_n(&ctx->stop, __ATOMIC_ACQUIRE))
>>> +		getppid();
>>> +	return NULL;
>>> +}
>> This isn't a bug, but could the trigger and target threads share one
>> function with a small per-thread argument (cpu and tid pointer)? And could
>> the repeated 2000000 / 100 poll bound become a named constant, like
>> TASK_WORK_RACE_ROUNDS?
>>
> I think this is worth addressing.
Hi， Mykyta

Thanks for your reviewing.
I carefully considered the 3 suggestions from the bot+bpf-ci,
and believe they are all necessary. I will incorporate them into
the v5 revision.

I will send out the v5 revision later (selftest changes only).

---

Thanks,

Yun Lu

>> [ ... ]
>>
>>> +		err = task_work_race_check_done(skel, seq);
>>> +		/*
>>> +		 * Variant 2 deletes the element right after READY, so losing
>>> +		 * the race against the scheduling kfunc is a valid outcome:
>>> +		 * the schedule itself fails with -EBUSY (ctx already FREED),
>>> +		 * and the retry on the next tracepoint invocation fails with
>>> +		 * -ENOENT because the element is gone.  Either way the round
>>> +		 * exercised the deletion paths; a later variant 0 round
>>> +		 * recreates the element.
>>> +		 */
>>> +		if (variant == 2 && (err == -EBUSY || err == -ENOENT))
>>> +			err = 0;
>> This isn't a bug, but can err actually be -EBUSY here, given that
>> race_sched_work() returns without publishing RESULT on -EBUSY? If not,
>> could the condition just check -ENOENT?
>>
>> [ ... ]
>>
>>> diff --git a/tools/testing/selftests/bpf/progs/task_work_race.c b/tools/testing/selftests/bpf/progs/task_work_race.c
>>> --- /dev/null
>>> +++ b/tools/testing/selftests/bpf/progs/task_work_race.c
>> [ ... ]
>>
>> ---
>> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
>> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>>
>> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/36538172291