From: sashiko-bot@kernel.org
To: "Joonho Lee" <mynameisjune111@gmail.com>, linux-sound@vger.kernel.org
Cc: virtualization@lists.linux.dev,
"Michael S. Tsirkin" <mst@redhat.com>,
"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH v29 17/17] ALSA: virtio: preserve playback progress across pause and buffer access
Date: Thu, 12 Nov 2026 06:04:02 +0000 [thread overview]
Message-ID: <sashiko-outbox-210494@kernel.org> (raw)
In-Reply-To: <20261112053446.73504-18-mynameisjune111@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] ALSA: virtio: ephemeral patch numbers and test notes in commit
message
--
commit 828a40dca88211506643733b87d449d53fefdce3
Author: Joonho Lee <mynameisjune111@gmail.com>
> ALSA: virtio: preserve playback progress across pause and buffer access
>
> TX completions can arrive after PAUSE closes transfer admission.
> Preserve that progress and schedule catch-up when the stream resumes or
> a rejected pause restores RUNNING. Cache device latency in stream-owned
> state so a late completion does not need to dereference the ALSA
> runtime. Clear both the cache and runtime delay on prepare and before
> RESET observes the hardware pointer.
>
> A playback pointer callback can also invoke ACK while the core has
> closed buffer-access admission, after the pointer helper has already
> accounted for completed hardware bytes. Track that callback context and
> refill only previously committed data using pcm_indirect.appl_ptr. Keep
> rejecting other ACKs while the gate is closed, and use the
> explicit-pointer helper from patch 16 for the refill. If
> runtime->control is absent, route the condition through the common
> playback validator and XRUN error path rather than returning before
> transfer failure handling.
>
> Use the existing indirect hw_queue_size to keep outstanding TX below one
> physical ring: buffer_bytes - period_bytes. Equal modulo cursors then
> mean no unobserved completion, and a non-interrupt HWSYNC cannot consume
> a hidden full-ring wrap before deferred period work. Continue using the
> ordinary ALSA pointer update for silence, drain, stop-threshold and
> wakeup policy.
>
> Check for pending progress or a latched transfer error again in the
> period worker under the PCM stream lock. A queued notification can
> outlive a paused RESET or an earlier pointer observation. Calling the
> period helper without new progress after resume can turn equal cursors
> into a false wrap when the core has backdated its pointer timestamp.
>
> This reduces queued buffering by one period. With two periods, only one
> period can be queued. Worst-case scheduling tolerance needs
> qualification.
>
> The final candidate was tested on ARM64 QEMU with KASAN and lockdep.
> RW/MMAP boundary pause, release, HWSYNC/poll, drop and reopen passed
> with two- and eight-period rings. RW/MMAP also passed accepted RESET
> from PREPARED followed by DRAIN and reopen, and accepted RESET while
> RUNNING after the full 2,048-frame buffer became available.
>
> A separate paired RW/MMAP gate fixture reproduced the baseline failure.
> The generic ALSA indirect helper invokes ACK for each pointer callback
> but masks its internal -EBADFD. Once hw_ptr == hw_io with no completion
> outstanding, virtio period-work progress suppresses further callbacks,
> so there is no ACK to retry the refill. Baseline stopped after 3,072
> completed bytes with 1,024 bytes in sw_ready. The candidate drained
> sw_ready and completed 4,096 bytes without any further client ACK. A
> test-only hook changed appl_ptr to 2,560 while only 2,048 frames were
> committed; the candidate refilled only committed data. The hostile
> mutation used a test-only kernel hook because ARM64 control-page mmap is
> unsupported. KASAN and lockdep had no diagnostics. KCSAN and physical
> audio were not tested. The tree through patch 15 was inspected but was
> not run as a separate control. Full-series runtime is not claimed here.
>
> Assisted-by: LLM
> Signed-off-by: Joonho Lee <mynameisjune111@gmail.com>
[Severity: Low]
This isn't a bug, but the commit message refers to mailing-list series
numbers ("patch 15" and "patch 16"), which lose their meaning once the
commits are applied to git history; naming
snd_pcm_indirect_playback_transfer_appl_ptr() or the prior commit subject
directly would be clearer. Also, the open-ended note ("Worst-case
scheduling tolerance needs qualification") and test-runner disclaimers
("The tree through patch 15 was inspected...", "Full-series runtime is not
claimed here.") belong in the cover letter or below the --- separator
rather than the permanent changelog.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261112053446.73504-1-mynameisjune111@gmail.com?part=17
prev parent reply other threads:[~2026-11-12 6:04 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 5:34 [PATCH v29 00/17] ALSA: virtio: preserve PCM progress Joonho Lee
2026-11-12 5:34 ` [PATCH v29 01/17] ALSA: pcm: mark stop-threshold accesses for capture policy sampling Joonho Lee
2026-11-12 5:39 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 02/17] ALSA: pcm: report partial progress under the stream lock Joonho Lee
2026-11-12 5:46 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 03/17] ALSA: pcm: add an optional reset operation " Joonho Lee
2026-11-12 5:44 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 04/17] ALSA: pcm: notify drivers after linked prepare completes Joonho Lee
2026-11-12 5:53 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 05/17] ALSA: pcm: serialize linked buffer actions Joonho Lee
2026-11-12 5:43 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 06/17] ALSA: virtio: propagate playback send failures through ACK Joonho Lee
2026-11-12 6:02 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 07/17] ALSA: virtio: Recover PCM state after a failed start Joonho Lee
2026-11-12 6:13 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 08/17] ALSA: virtio: Retain queued messages through device reset Joonho Lee
2026-11-12 6:00 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 09/17] ALSA: virtio: bound PCM transfers and retain DMA buffers Joonho Lee
2026-11-12 6:00 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 10/17] ALSA: virtio: Keep control payloads alive through DMA completion Joonho Lee
2026-11-12 5:44 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 11/17] ALSA: virtio: wait through signals for PCM teardown Joonho Lee
2026-11-12 5:49 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 12/17] ALSA: virtio: use request-owned capture and serialize recovery Joonho Lee
2026-11-12 6:08 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 13/17] ALSA: virtio: prioritize capture period work Joonho Lee
2026-11-12 5:46 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 14/17] docs: describe virtio-sound capture options Joonho Lee
2026-11-12 5:46 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 15/17] ALSA: virtio: reject invalid playback completions Joonho Lee
2026-11-12 5:53 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 16/17] ALSA: pcm: add an explicit application pointer to indirect playback transfer Joonho Lee
2026-11-12 5:51 ` sashiko-bot
2026-11-12 5:34 ` [PATCH v29 17/17] ALSA: virtio: preserve playback progress across pause and buffer access Joonho Lee
2026-11-12 6:04 ` sashiko-bot [this message]
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=sashiko-outbox-210494@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=eperezma@redhat.com \
--cc=linux-sound@vger.kernel.org \
--cc=mst@redhat.com \
--cc=mynameisjune111@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=virtualization@lists.linux.dev \
/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.