All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Joonho Lee <mynameisjune111@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>, 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: Re: [RFC PATCH 2/2] ALSA: pcm: refresh capture pointers before drain
Date: Thu, 15 Oct 2026 17:53:42 +0200	[thread overview]
Message-ID: <87mrsf6juh.wl-tiwai@suse.de> (raw)
In-Reply-To: <core-drain-helper-reply.0c1099dbd0ca4a37@gmail.com>

On Thu, 15 Oct 2026 01:52:03 +0200,
Joonho Lee wrote:
> 
> Hi Takashi,
> 
> Thanks, I've reworked the local version along those lines.
> 
> The helper takes snd_pcm_link_rwsem for reading and updates each running
> member under its own stream lock. It uses snd_pcm_update_hw_ptr() for both
> playback and capture. I call it after the existing pause-resume step so a
> paused capture stream gets its final pointer update too. The pause and
> drain-init actions remain outside the link rwsem.
> 
> A pointer error now follows the usual XRUN path and returns -EPIPE before
> drain-init. This restores the group-wide error handling from v2 and removes
> the "notify" boolean argument introduced in v3 proposal.
> 
> While checking this version, I also confirmed three problems in the first
> patch: 
> 1) a reader already waiting for data could lose the capture tail
> 2) finishing a capture read could stop a linked playback stream
> 3) DELAYand SYNC_PTR(HWSYNC) rejected capture DRAINING. The local fixes preserve
> the unread count when waking the reader, finish capture with
> snd_pcm_drain_done(), and use the cached pointer for capture hwsync.
> 
> I reproduced all three failures with the helper plus the old first patch,
> then checked the fixes in both atomic and nonatomic modes. The blocked
> reader now receives all 64 final frames, capture EOF leaves linked playback
> in DRAINING, and both position queries succeed without another pointer
> callback. The 26 linked-stream checks, including paused drain and pointer
> errors, and the 10 existing lifecycle/reset cases also passed under ARM64
> QEMU with KASAN and lockdep, but physical real-world device testing is still pending in this time.
> 
> There is one concurrency point I'd like to check. The helper releases the
> link rwsem before drain-init, and snd_pcm_link() allows another RUNNING
> stream to join in that interval. The new member could enter drain-init
> without being visited by the refresh loop.
> My question is, should we handle concurrent linking across these two steps, or leave that outside this change's scope?

I guess we can leave this for now.  The invalid state like OPEN or
SUSPENDED is checked at snd_pcm_pre_drain_init().


thanks,

Takashi

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

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-14  3:30 [RFC PATCH 0/2] ALSA: pcm: preserve capture tail during drain Joonho Lee
2026-10-14  3:30 ` [RFC PATCH 1/2] ALSA: pcm: allow capture reads while draining Joonho Lee
2026-10-14  3:30 ` [RFC PATCH 2/2] ALSA: pcm: refresh capture pointers before drain Joonho Lee
2026-10-14  8:15   ` Takashi Iwai
2026-10-14  8:35     ` Takashi Iwai
2026-10-14 15:20       ` Joonho Lee
2026-10-14 15:24         ` [RFC PATCH v3 0/2] ALSA: pcm: preserve capture tail during drain Joonho Lee
2026-10-14 15:24           ` [RFC PATCH v3 1/2] ALSA: pcm: allow capture reads while draining Joonho Lee
2026-10-14 15:24           ` [RFC PATCH v3 2/2] ALSA: pcm: refresh capture pointers in the drain action Joonho Lee
2026-10-14 15:33         ` [RFC PATCH 2/2] ALSA: pcm: refresh capture pointers before drain Takashi Iwai
2026-10-14 23:52           ` Joonho Lee
2026-10-15 15:53             ` Takashi Iwai [this message]
2026-10-14  8:15 ` [RFC PATCH v2 0/2] ALSA: pcm: preserve capture tail during drain Joonho Lee
2026-10-14  8:15   ` [RFC PATCH v2 1/2] ALSA: pcm: allow capture reads while draining Joonho Lee
2026-10-14  8:15   ` [RFC PATCH v2 2/2] ALSA: pcm: refresh capture pointers before drain Joonho Lee

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=87mrsf6juh.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=mynameisjune111@gmail.com \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.