mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joonho Lee <mynameisjune111@gmail.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Takashi Iwai <tiwai@suse.com>, Jaroslav Kysela <perex@perex.cz>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org
Subject: [PATCH v5 0/2] ALSA: pcm: preserve capture tail during drain
Date: Fri, 16 Oct 2026 08:48:03 +0900	[thread overview]
Message-ID: <v5-core-capture-drain-0.e9b40d3bc08c4162@gmail.com> (raw)

Capture drain can leave final frames buffered after the device stops.
This series lets userspace read those frames and refreshes the linked
streams' hardware pointers before drain-init.

Patch 1 allows capture reads in DRAINING, preserves the unread count when
waking a blocked reader, and finishes capture with snd_pcm_drain_done()
so linked playback can continue draining. DELAY and SYNC_PTR(HWSYNC) use
the cached final capture pointer after capture stops.

Patch 2 refreshes each running member under its stream lock while holding
snd_pcm_link_rwsem for reading. It updates both playback and capture,
after the existing pause-resume step. The pause and drain-init actions
remain outside the link rwsem. Pointer errors follow the normal XRUN
path and return -EPIPE before drain-init.

Changes since RFC v4:
- Submit as a non-RFC series following Takashi's response.
- No changes to either patch body, including the commit message, diff,
  and existing trailers. This cover and the mail headers are updated.

Takashi said both patches look OK and that he can try merging a non-RFC
series:
https://lore.kernel.org/all/87ld7z6jsk.wl-tiwai@suse.de/
Previous RFC v4:
https://lore.kernel.org/all/rfc-v4-core-capture-drain-0.b56779f7976d4657@gmail.com/
Implementation and test discussion:
https://lore.kernel.org/all/core-drain-helper-reply.0c1099dbd0ca4a37@gmail.com/

The five-patch virtio-snd lifetime v3 series is unchanged:
https://lore.kernel.org/all/cover.1791881787.git.mynameisjune111@gmail.com/
The base and prerequisite IDs below preserve the tested integration:
apply the five lifetime patches, then these two core patches. Replace
both earlier core patches when testing this revision. Core has no
dependency on the generic control-wait or VZ compatibility RFC. This
submission does not revise either companion series.

The following validation is from RFC v4's unchanged source; no new
runtime tests were run for this mail-only revision.

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 v5
core source matches the tested source byte for byte.

These tests use synthetic drivers and modified fault/reset backends.

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

             reply	other threads:[~2026-10-15 23:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 23:48 Joonho Lee [this message]
2026-10-15 23:48 ` [PATCH v5 1/2] ALSA: pcm: allow capture reads while draining Joonho Lee
2026-10-15 23:48 ` [PATCH v5 2/2] ALSA: pcm: refresh linked pointers before draining Joonho Lee
2026-10-16  8:20 ` [PATCH v5 0/2] ALSA: pcm: preserve capture tail during drain Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=v5-core-capture-drain-0.e9b40d3bc08c4162@gmail.com \
    --to=mynameisjune111@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®