Re: [RFC PATCH v4 0/2] ALSA: pcm: preserve capture tail during drain

[Takashi Iwai]

On Thu, 15 Oct 2026 02:35:59 +0200,
Joonho Lee wrote:
> 
> This v4 replaces both patches in the core capture-drain v3 series. It
> follows Takashi Iwai's suggestion to refresh linked pointers in a helper
> before drain-init and fixes three tail-handling problems in patch 1.
> 
> Patch 1 allows buffered capture reads in DRAINING. When drain wakes a
> reader waiting for data, wait_for_avail() returns the remaining frame
> count. Capture EOF uses snd_pcm_drain_done(), so a linked playback stream
> can continue draining. DELAY and SYNC_PTR(HWSYNC) use the cached final
> capture pointer without calling the driver again after capture stops.
> Sashiko's review identified these three problems in the earlier patch.
> 
> Patch 2 takes snd_pcm_link_rwsem for reading and updates each running
> member under its own stream lock. It calls snd_pcm_update_hw_ptr() for
> both playback and capture. The helper runs after the existing pause-resume
> step, allowing a paused capture stream to receive its final update.
> The pause and drain-init actions remain outside the link rwsem.
> 
> A pointer error follows the ordinary XRUN path and returns -EPIPE before
> drain-init. This restores v2's group-wide error handling. V3 instead put
> the failing member in SETUP and could return success from blocking drain
> while another member retained its tail. V4 removes v3's notify argument
> and the conditional notifications in the pointer update code.
> 
> Previous core v3:
> https://lore.kernel.org/all/rfc-v3-core-capture-drain-0.cf2e307fcac34b6a@xxxxxxxxx/
> Takashi's latest suggestion:
> https://lore.kernel.org/all/87jynkcn60.wl-tiwai@xxxxxxx/
> My implementation and test report:
> https://lore.kernel.org/all/core-drain-helper-reply.0c1099dbd0ca4a37@xxxxxxxxx/
> 
> The separate five-patch virtio-snd lifetime v3 series is unchanged:
> https://lore.kernel.org/all/cover.1791881787.git.mynameisjune111@xxxxxxxxx/
> Apply those five patches to the public base below, then these two patches.
> Remove both old core patches before applying v4. Core has no dependency
> on the generic control-wait or VZ compatibility RFC. The lifetime stack
> is pinned here to reproduce the tested integration. Neither companion
> RFC is revised by this series. A future VZ revision will need the new
> core prerequisite IDs.
> 
> Validation used ARM64 QEMU with KASAN and lockdep:
> - 26 linked-stream checks passed across atomic and nonatomic modes,
>   including paused drain, first/later member pointer errors, normal XRUN
>   handling, tail reads, and unlink/prepare/reopen recovery.
> - The three patch-1 failures were reproduced with the helper and the old
>   first patch in both locking modes. All six corresponding fixed cases
>   passed: a blocked reader received all 64 final frames, capture EOF
>   left linked playback in DRAINING, and both position queries succeeded
>   without another pointer callback.
> - Four additional blocked-reader runs compared baseline and fixed modules
>   in both modes with a stronger gate: thread sleep and a pointer callback
>   after START. They confirmed the baseline loss and fixed 64-frame read.
> - The 10 existing lifecycle and timeout/reset scenarios passed, including
>   held STOP/RELEASE, SIGKILL, reset, and subsequent I/O recovery.
> - No KASAN, lockdep, or panic diagnostics appeared in the 54 selected
>   logs, which include the baseline behavioral-failure comparisons.
> 
> The full Image and modules were first built with the new helper and the
> old first patch. After fixing the three tail issues, sound/core was
> rebuilt with W=1 against that same configuration and symbol versions,
> and the corrected PCM module was used for the runs above. The module
> build had no warnings or errors. The full build had 517 existing
> -Woverride-init warnings in arch/arm64 outside sound/. The exported v4
> core source matches the tested source byte for byte.
> 
> These tests use synthetic drivers and modified fault/reset backends.
> Physical-device and Virtualization.framework microphone testing of this
> core revision is still pending. Concurrent LINK, wraparound, and
> forward/rewind behavior have not been exercised by this test set.
> The updated reproducer and logs are local; the earlier public package
> contains an older core revision. There is no new reproducer upload for
> this candidate.
> 
> One design question remains: the helper releases the link rwsem before
> drain-init, and snd_pcm_link() permits another RUNNING stream to join in
> that interval. That member could enter drain-init without a refresh by
> the helper. Should this change protect the membership across both steps,
> or should concurrent linking be handled separately? I have reviewed this
> interval in the source but have not reproduced it with a stress test.
> 
> Do the restored group-wide XRUN/-EPIPE behavior and cached capture hwsync
> semantics look appropriate? Which physical-driver coverage would you
> want before this can move beyond RFC?
> 
> LLM assistance was used for implementation, reproducer development,
> analysis, and documentation. I reviewed the changes and test evidence.
> Assisted-by: LLM
> 
> Joonho Lee (2):
>   ALSA: pcm: allow capture reads while draining
>   ALSA: pcm: refresh linked pointers before draining

Both patches look OK.  Once when you submit a non-RFC patch set, I can
try merging.


thanks,

Takashi