> task_work_run() assumes every stress run observes both scheduler
> contention and, when the delete thread is enabled, cancellation of at
> least one pending callback.
>
> Neither outcome is guaranteed. Contention is observed only when another
> scheduler selects the same one of 128 map values while its task work is
> outstanding. A valid run can therefore have no scheduling errors. This
> was reproduced with a single scheduler: more than one million callbacks
> were scheduled and completed while schedule_error remained zero.
This isn't a bug, but would it read more clearly to say something like 'the
task_work_stress test helper' (or name the file) instead of the bare
task_work_run() in the opening sentence? There are three functions with
that name in the tree: kernel/task_work.c, prog_tests/test_task_work.c, and
the static helper being changed here in prog_tests/task_work_stress.c, so
the bare name could be mistaken for the kernel function on first reading.
This isn't a bug, but was nthreads reduced locally to get the
single-scheduler run quoted here? The test hardcodes 'int nthreads = 16;'
(prog_tests/task_work_stress.c:50) and the only environment knob is
BPF_TASK_WORK_TEST_TIME for the duration. A reader trying to reproduce the
quoted numbers has no way to get there without editing the file. It might
help to say so explicitly, or give the 16-thread numbers, since the test
has no knob for the thread count.
> Likewise, a successful map deletion may remove a value after its
> callback has completed. delete_success can therefore be nonzero without
> callback_success being smaller than callback_scheduled.
>
> Drop the assertion that schedule_error is nonzero. Keep requiring exact
> callback accounting when deletion is disabled. With deletion enabled,
> allow equal counts but still reject callback_success greater than
> callback_scheduled.
>
> Fixes: c6ae18e0af5e ("selftests/bpf: add bpf task work stress tests")
> Signed-off-by: Yun Lu <[email protected]>
---
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/35199472874
