Hi Takashi, This twelve-patch series replaces v14 and is based on a4311e9447bbb219044db38897f95be112f46a8a.
The follow-up closes a PCM ACK race after the core clears stop_operating and before sync_stop finishes. If a substream is already stopped with a transfer XRUN latched, playback and both capture ACK paths now return -EBADFD before they can re-enter the XRUN path and re-arm stop_operating. A transfer XRUN on an active stream keeps the existing -EPIPE behavior. A capture tail remains available during DRAINING when no transfer XRUN is latched. I reproduced the race in playback and capture. In each baseline run, the ACK returned -EPIPE, changed the PCM state to XRUN, and re-armed stop_operating. The candidate returned -EBADFD and kept the stream PREPARED with stop_operating clear. The capture comparisons cover a synthetic stage-04 fixture and the real virtio-snd module at stage 12. A separate instrumented stage-12 QEMU run placed playback ACK in the core sync_stop handoff window; its production playback ACK functions match the candidate source byte for byte. The tests also checked the clean DRAINING tail and the latched-XRUN case. All twelve cumulative stages built on 7.3.0-rc7-virtio-next-kasan. The six ACK/XRUN race comparisons and three ops regression runs completed with exit status zero. KASAN and lockdep reported no diagnostics. KCSAN was not enabled. The stage-04 fixture logs include ignored notices for five module parameters; these are recorded separately from kernel diagnostics. No physical-device capture or suspend test was performed. The harness leaves behavior_passed unset, so the reported behavior is derived from the guest serial markers. The attached evidence records source, build, image, module, fixture, and serial-log hashes. Assisted-by: LLM Thanks, Joonho base-commit: a4311e9447bbb219044db38897f95be112f46a8a
