Re: [PATCH bpf-next 0/2] bpf: Fix task work round ownership race

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

On 9/18/26 9:00 AM, Yun Lu wrote:
> From: Yun Lu <luyun@kylinos.cn>
> 
> This series fixes a race in the bpf_task_work scheduling kfuncs and
> adds a regression test for it.
> 
> A task_work callback scheduled for a task running on another CPU can
> complete before bpf_task_work_irq() regains control after
> task_work_add().  The callback's cleanup releases ctx->task, so a
> concurrent map value deletion that publishes the FREED state makes the
> resumed irq_work handler call task_work_cancel(NULL, &ctx->work),
> dereferencing task_struct::task_works through a NULL task (RIP at
> task_work_cancel+0xd, RDI == 0, CR2 at the task_works offset).  The
> same cancellation is reached when the deletion wins before the
> callback runs and the callback's bailout path drops the last ctx
> refcount, clearing ctx->task.
> 
> Patch 1 gives each scheduling round an ownership count: the irq_work
> scheduler, the published callback and an asynchronous canceller hold a
> reference while using this round's task/prog/work, and only the last
> user releases them, before the ctx can be reused from STANDBY.  The
> count is zero based with the STANDBY -> PENDING transition acting as
> the zero-to-one gate, so a finished round cannot be revived: a
> canceller either pins a still-active round (ctx->task guaranteed
> valid) or declines to cancel.  Separate irq_work objects for
> scheduling, cancellation and deferred destruction avoid reinitializing
> an irq_work that may still be queued or running.  FREED remains
> terminal and the scheduling path stays atomic-only, preserving NMI
> safety.
> 
> The race window between task_work_add() and the SCHEDULING ->
> SCHEDULED cmpxchg is only a few instructions wide, so the fix was
> verified with a deterministic reproduction that widens exactly this
> window with a debug delay, while scheduling cross-CPU and deleting the
> map value concurrently: without the fix the kernel panics reliably;
> with it, all interleavings complete.  A 900-round stress test rotating
> through ctx reuse, deletion after the callback and deletion right
> after scheduling also runs clean, with no leaks reported by kmemleak.
> 
> Patch 2 adds a selftest that keeps steady pressure on the
> interleaving: it schedules cross-CPU, deletes the map value at
> different points of a round, uses READY/DONE handshakes so scheduling
> errors cannot be missed, and tags every callback with a generation so
> a late callback cannot satisfy a later round's assertions.
> 

I could not reproduce the kernel crash on my computer, the test is also
very flaky:

./test_progs -t task_work_race
serial_test_task_work_race:FAIL:round ready unexpected error: -5 (errno 2)
#513     task_work_race:FAIL

Could you please share a bit more on how to repro the crash, feel free to
share your config, arch, any details on how you run it.

> Yun Lu (2):
>   bpf: Fix task work round ownership during cancellation
>   selftests/bpf: Add task work round ownership race test
> 
>  kernel/bpf/helpers.c                                  | 123 ++++++++++--
>  .../selftests/bpf/prog_tests/test_task_work.c         | 283 +++++++++++++++++++++
>  .../selftests/bpf/progs/task_work_race.c              | 125 ++++++++
>  3 files changed, 503 insertions(+), 28 deletions(-)
>