在 2026/9/17 17:00, [email protected] 写道:
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.
Agreed. The opening sentence will be reworded to "The task_work_run()
helper in prog_tests/task_work_stress.c assumes ...", so it cannot be
mistaken for the kernel function of the same name.
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.
Yes, that run came from a modified copy of the test with the scheduler
thread count reduced to 1. v2 will state this explicitly: "reproduced
with a modified copy of the test running a single scheduler thread
(nthreads is hardcoded to 16 and the test has no knob for it)".
These are commit message changes only; the code will be identical to
v1, and 2/2 is unchanged. If there are no further comments on the two
patches, I will send out v2 later.
Thanks,
Yun Lu
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
