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

[Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>]

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.

> [ ... ]
> 
>> +		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