[PATCH v15 00/12] ALSA: virtio: staged capture recovery and PCM ACK handoff

[Joonho Lee]

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