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 v5 05/11] ALSA: virtio: Keep control payloads alive through DMA completion
Date: Tue, 27 Oct 2026 23:55:42 +0000 [thread overview]
Message-ID: <sashiko-outbox-187245@kernel.org> (raw)
In-Reply-To: <20261027234334.32551-6-mynameisjune111@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] ALSA: virtio: misaligned control value access in virtsnd_kctl_get()
--
commit 15e13c28bcb1079484dfa947a5ae6109ebb5b3c9
Author: Joonho Lee <mynameisjune111@gmail.com>
ALSA: virtio: Keep control payloads alive through DMA completion
This commit moves control request and response payloads into a
reference-counted DMA buffer owned by struct virtio_snd_msg so caller
buffers are not exposed to DMA after a timeout or interruption. It also
aligns each scatterlist region to the greater of the DMA cacheline size
and the alignment of struct virtio_snd_ctl_value.
> diff --git a/sound/virtio/virtio_ctl_msg.c b/sound/virtio/virtio_ctl_msg.c
> index 7114bea4033a5..2e0ff15e729da 100644
> --- a/sound/virtio/virtio_ctl_msg.c
> +++ b/sound/virtio/virtio_ctl_msg.c
[ ... ]
> @@ -85,20 +161,85 @@ void *virtsnd_ctl_msg_response(struct virtio_snd_msg *msg)
> struct virtio_snd_msg *virtsnd_ctl_msg_alloc(size_t request_size,
> - size_t response_size, gfp_t gfp)
> + size_t response_size,
> + size_t request_data_size,
> + size_t response_data_size,
> + gfp_t gfp)
> {
[ ... ]
> + cache_alignment = dma_get_cache_alignment();
> + if (cache_alignment <= 0)
> + return NULL;
> + /* DMA coherence does not remove the CPU's type alignment requirement. */
> + alignment = max_t(size_t, cache_alignment,
> + __alignof__(struct virtio_snd_ctl_value));
[ ... ]
> diff --git a/sound/virtio/virtio_kctl.c b/sound/virtio/virtio_kctl.c
> index 45f7b6a5b3080..4cf75dedbe9a3 100644
> --- a/sound/virtio/virtio_kctl.c
> +++ b/sound/virtio/virtio_kctl.c
[ ... ]
> @@ -161,10 +163,12 @@ static int virtsnd_kctl_get(struct snd_kcontrol *kcontrol,
> unsigned int i;
> int rc;
>
> - msg = virtsnd_ctl_msg_alloc(request_size, response_size, GFP_KERNEL);
> + msg = virtsnd_ctl_msg_alloc(request_size, response_size, 0, 0,
> + GFP_KERNEL);
> if (!msg)
> return -ENOMEM;
[Severity: Medium]
Does packing both the response header and struct virtio_snd_ctl_value into
sg_response leave kvalue misaligned in virtsnd_kctl_get()?
In virtsnd_ctl_msg_alloc(), each scatterlist region is aligned to at least
__alignof__(struct virtio_snd_ctl_value), which is 8 bytes because of the
__le64 integer64[64] array.
In virtsnd_kctl_put(), the request header is struct virtio_snd_ctl_hdr (8
bytes), so placing kvalue immediately after it preserves 8-byte alignment.
However, in virtsnd_kctl_get(), response_data_size is passed as 0 and
response_size is sizeof(struct virtio_snd_hdr) + sizeof(*kvalue), with
kvalue computed right after the 4-byte struct virtio_snd_hdr:
sound/virtio/virtio_kctl.c:virtsnd_kctl_get() {
...
kvalue = (void *)((u8 *)virtsnd_ctl_msg_response(msg) +
sizeof(struct virtio_snd_hdr));
switch (type) {
...
case VIRTIO_SND_CTL_TYPE_INTEGER64:
for (i = 0; i < count; ++i)
uvalue->value.integer64.value[i] =
le64_to_cpu(kvalue->value.integer64[i]);
break;
...
}
Since virtsnd_ctl_msg_response(msg) is aligned to a multiple of 8 bytes and
sizeof(struct virtio_snd_hdr) is 4 bytes, kvalue is guaranteed to land at an
8n + 4 address, causing unaligned 64-bit loads when reading a
VIRTIO_SND_CTL_TYPE_INTEGER64 control.
Should the control value payload be placed in response_data (or the
request/response payloads placed in sg_request_data and sg_response_data) so
that kvalue starts on an aligned boundary?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261027234334.32551-1-mynameisjune111@gmail.com?part=5
next prev parent reply other threads:[~2026-10-27 23:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-27 23:43 [PATCH v5 00/11] ALSA: virtio: staged capture and dsnoop recovery Joonho Lee
2026-10-27 23:43 ` [PATCH v5 01/11] ALSA: virtio: Propagate PCM send failures through ACK Joonho Lee
2026-10-28 0:09 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 02/11] ALSA: virtio: Recover PCM state after a failed start Joonho Lee
2026-10-28 0:18 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 03/11] ALSA: virtio: Retain queued messages through device reset Joonho Lee
2026-10-28 0:15 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 04/11] ALSA: virtio: Keep PCM DMA buffers alive through device ownership Joonho Lee
2026-10-27 23:59 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 05/11] ALSA: virtio: Keep control payloads alive through DMA completion Joonho Lee
2026-10-27 23:55 ` sashiko-bot [this message]
2026-10-27 23:43 ` [PATCH v5 06/11] ALSA: virtio: wait through signals for PCM teardown Joonho Lee
2026-10-28 0:07 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 07/11] ALSA: virtio: stage VZ capture and restart paused streams Joonho Lee
2026-10-28 0:19 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 08/11] ALSA: virtio: account staged capture reads before RX refill Joonho Lee
2026-10-27 23:43 ` [PATCH v5 09/11] ALSA: virtio: prioritize staged capture period work Joonho Lee
2026-10-28 0:03 ` sashiko-bot
2026-10-27 23:43 ` [PATCH v5 10/11] ALSA: pcm: mark stop-threshold accesses for capture policy sampling Joonho Lee
2026-10-27 23:43 ` [PATCH v5 11/11] ALSA: virtio-snd: fix dsnoop capture with staged buffers Joonho Lee
2026-10-28 0:13 ` sashiko-bot
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-187245@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox