Hi Felix, > Shouldn't cancel_delayed_work_sync wait for the worker function to > exit? I don't see how that can race with the re-scheduling in the > worker function itself.
You're right, my UAF framing was wrong on current kernels. I checked the workqueue code: __cancel_work_sync() marks the work disabled in its off-queue data while it flushes, and queue_delayed_work_on() drops the requeue via clear_pending_if_disabled(). Self-reschedule from a running handler, delayed or not, can't survive the cancel. The argument that does stand: the cancel only runs at last-VM destroy during process exit (gpuvm_destroy_cb, when n_vms hits 0). On surprise removal that path itself can stall — the SIGBUS'd task deadlocks in its own exit path (SVM migrate -> fence that never signals, patch 3/3), so process_info teardown never runs and nobody ever calls the cancel. That whole window is where the ~11k-cycle spin at 1ms delay happened, holding process_info->lock and notifier_lock each round until soft-lockup. So the -ENODEV check isn't about racing the cancel — it's the stop condition for the window where the device's lifetime has ended but process_info's hasn't. Transient errors still retry as before. Olivier
