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

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@gmail.com/ (local)
Takashi's latest suggestion:
https://lore.kernel.org/all/87jynkcn60.wl-tiwai@suse.de/ (local)
My implementation and test report:
https://lore.kernel.org/all/core-drain-helper-reply.0c1099dbd0ca4a37@gmail.com/ (local)

The separate five-patch virtio-snd lifetime v3 series is unchanged:
https://lore.kernel.org/all/cover.1791881787.git.mynameisjune111@gmail.com/ (local)
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

 sound/core/pcm_lib.c    | 16 ++++++++++------
 sound/core/pcm_native.c | 27 ++++++++++++++++++++++++++-
 2 files changed, 36 insertions(+), 7 deletions(-)

base-commit: 8d70e364e866bdfca81eee24d0688fac9472cfb9
prerequisite-patch-id: 39fb327a004c966ab90f66a34a64bbdbb3ffb475
prerequisite-patch-id: 7c6bc344656fd839ae0d697ba18d66ac0b47827a
prerequisite-patch-id: 9dd290ac3147fa7b49a475d7df8a6172778f2860
prerequisite-patch-id: f4c24a5e441343a690f4ac2437f181c815bc23d0
prerequisite-patch-id: ab4a5b770247a65272ab7af18a75a147daf81287