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

[Joonho Lee <mynameisjune111@gmail.com>]

This updates the core capture-drain RFC to v3. The separate five-patch
virtio-snd lifetime v3 series remains unchanged.

Patch 1 still permits reads of buffered capture data in DRAINING.
Patch 2 follows Takashi Iwai's suggestion to refresh a running capture
pointer inside snd_pcm_do_drain_init(), under the existing drain action's
stream and group locks. It removes v2's separate pre-action traversal and
link rwsem handling.

The pointer helper accepts a notify flag. Drain init disables nested XRUN
and drain-complete actions and owns the subsequent stop/state transition.
The direct SNDRV_PCM_POS_XRUN return from a driver's pointer callback needs
the same guard as the stop-threshold path; the sketch did not guard that
early branch. Ordinary pointer updates and period notifications still use
notify=true.

There is an observable difference from v2 on a capture pointer error.
V2 returned EPIPE and put the linked group in XRUN. The new callback ends
the failing member in SETUP and continues processing other members. A
blocking capture-only drain returns 0 if the action otherwise succeeds;
an unaffected member's valid tail can remain readable in DRAINING. The
failed member has no readable tail in SETUP. The existing nonblocking
EAGAIN policy is unchanged. This policy remains open for review.

Takashi's later reply proposed calling snd_pcm_update_hw_ptr() directly:
https://lore.kernel.org/all/87y0c0el29.wl-tiwai@suse.de/
I tested that literal alternative with a synthetic linked capture driver.
A later member returning SNDRV_PCM_POS_XRUN recursively enters
snd_pcm_stop() while the drain action already holds the group locks.
Lockdep reports recursive acquisition of group->lock (atomic) and
group->mutex (nonatomic); both runs remain blocked until the 45-second
host bound. Unlinked controls complete with both implementations.
The candidate therefore retains notify=false and guards both XRUN paths.
The deadlock above was reproduced with the later direct-call proposal.
The submitted v2 used a separate pre-action traversal.

Initial review:
https://lore.kernel.org/all/8733u8g0kh.wl-tiwai@suse.de/
Previous core v2:
https://lore.kernel.org/all/rfc-v2-core-capture-drain-0.2eddd58a796e497f@gmail.com/
Lifetime v3 prerequisite:
https://lore.kernel.org/all/cover.1791881787.git.mynameisjune111@gmail.com/

Apply core patches 1 and 2 after the five lifetime v3 patches on the public
base below. Core does not require the generic wait or VZ profile patch;
this base is pinned to reproduce the integrated test stack. Replace old
core 2/2 with this revision.

Validation on the rebuilt 7.3.0-rc6-snd-rfc-tiwai-lockdep ARM64 kernel:
- Full Image and module build with W=1, KASAN, lockdep and atomic-sleep
  debugging: no errors or sound warnings. The base emitted 517
  -Woverride-init warnings outside sound/.
- All 10 QEMU scenarios passed: short capture tails, drop, delayed
  PREPARE/START/STOP/RELEASE, pending RX after RELEASE, and actual held
  STOP/RELEASE with SIGKILL, timeout, reset and subsequent I/O recovery.
- All 24 synthetic linked cases passed across atomic and nonatomic locks:
  zero/tail data, sentinel/threshold faults in the first/later member,
  normal active XRUN reporting, unlink/prepare and close/reopen recovery.
  The shared-STOP fixture also checks a later member's frozen final tail.
- Two additional unlinked candidate controls passed and matched the
  literal proposal's unlinked state, read error and recovery behavior.
- No KASAN or lockdep diagnostics occurred in candidate runs; the two
  intentional alternative-module failures are recorded separately.
- The corrected harness invocations passed 19 lifecycle and 5 direct-reset
  tests; the initial collection-error log is retained separately.
  Both signed patches pass strict checkpatch without errors or warnings.
The QEMU fault/reset fixtures use modified test backends. The build
includes the unchanged companion patches.
No new physical microphone or Virtualization.framework test is claimed.
Mixed capture/playback linked groups and physical drivers remain untested.
Nonblocking EAGAIN preservation was code-reviewed; runtime testing of
that behavior remains pending.

Questions:
- Is the proposed drain-time error policy (local SETUP and successful
  blocking drain) intended, or should an error be reported after all
  members have been stopped?
- Is refreshing each member immediately before its STOP sufficient for
  drivers whose first STOP freezes linked hardware, provided later pointer
  callbacks report their stable final positions?
- Which additional physical-driver or mixed capture/playback group tests
  should be required before this becomes a non-RFC core change?

Assisted-by: LLM

The new linked reproducer and comparison logs are currently local. The
earlier public reproducer package contains the core v2 implementation.
This revision does not claim a new public reproducer URL.

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