From: sashiko-bot@kernel.org
To: "Bard Liao" <yung-chuan.liao@linux.intel.com>,
linux-sound@vger.kernel.org
Subject: Re: [PATCH 2/2] soundwire: stream: Fix bandwidth leak in multi-link aggregation failure
Date: Mon, 02 Nov 2026 06:16:43 +0000 [thread overview]
Message-ID: <sashiko-outbox-192944@kernel.org> (raw)
In-Reply-To: <20261102060437.824814-3-yung-chuan.liao@linux.intel.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] soundwire: stream: bank state desync in _sdw_prepare_stream() rollback
- [High] soundwire: stream: incomplete port and lane rollback in _sdw_prepare_stream()
--
commit 9b420de314ec50416d79ce337f8a1fedd698be52
Author: David Lin <david.lin@intel.com>
soundwire: stream: Fix bandwidth leak in multi-link aggregation failure
This commit snapshots struct sdw_bus_params for each master in a stream
before preparing it and restores all masters' parameters on failure in
_sdw_prepare_stream() to prevent bandwidth leaks on earlier links.
> diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c
> index 96613dd0677c4..86d951cc92f72 100644
> --- a/drivers/soundwire/stream.c
> +++ b/drivers/soundwire/stream.c
> @@ -1477,19 +1477,22 @@ static int _sdw_prepare_stream(struct sdw_stream_runtime *stream,
> struct sdw_master_runtime *m_rt;
> struct sdw_bus *bus;
> struct sdw_master_prop *prop;
> - struct sdw_bus_params params;
> int ret;
>
> + /* Pre-pass: snapshot original bus parameters for all masters */
> + list_for_each_entry(m_rt, &stream->master_list, stream_node)
> + m_rt->params_backup = m_rt->bus->params;
> +
> /* Prepare Master(s) and Slave(s) port(s) associated with stream */
> list_for_each_entry(m_rt, &stream->master_list, stream_node) {
> bus = m_rt->bus;
> prop = &bus->prop;
> - memcpy(¶ms, &bus->params, sizeof(params));
>
> /* TODO: Support Asynchronous mode */
> if ((prop->max_clk_freq % stream->params.rate) != 0) {
> dev_err(bus->dev, "Async mode not supported\n");
> - return -EINVAL;
> + ret = -EINVAL;
> + goto restore_params;
> }
>
> if (update_params) {
> @@ -1540,7 +1543,13 @@ static int _sdw_prepare_stream(struct sdw_stream_runtime *stream,
> return ret;
>
> restore_params:
> - memcpy(&bus->params, ¶ms, sizeof(params));
> + /*
> + * Revert all masters to their snapshotted original parameters.
> + * Any master that was not modified will safely revert to its own original state.
> + */
> + list_for_each_entry(m_rt, &stream->master_list, stream_node)
> + m_rt->bus->params = m_rt->params_backup;
[Severity: High]
Can this rollback desynchronize bus->params.curr_bank and
bus->params.next_bank from the active hardware register bank when failure
occurs during or after do_bank_switch()?
At the start of _sdw_prepare_stream(), m_rt->params_backup copies the entire
struct sdw_bus_params, including the pre-switch curr_bank and next_bank
values. Later in _sdw_prepare_stream(), do_bank_switch() switches the
hardware bank and flips curr_bank and next_bank (via sdw_bank_switch() or
sdw_ml_sync_bank_switch()), followed by the loop calling
sdw_prep_deprep_ports():
ret = do_bank_switch(stream);
if (ret < 0) {
pr_err("%s: do_bank_switch failed: %d\n", __func__, ret);
goto restore_params;
}
list_for_each_entry(m_rt, &stream->master_list, stream_node) {
bus = m_rt->bus;
/* Prepare port(s) on the new clock configuration */
ret = sdw_prep_deprep_ports(m_rt, true);
if (ret < 0) {
dev_err(bus->dev, "Prepare port(s) failed ret = %d\n",
ret);
goto restore_params;
}
}
If sdw_prep_deprep_ports() fails on any link (or if do_bank_switch() fails on
a later link after an earlier link has already switched banks), jumping to
restore_params overwrites m_rt->bus->params with m_rt->params_backup across
every master in stream->master_list.
Wouldn't that revert curr_bank and next_bank to their pre-switch values while
the hardware remains on the newly switched bank (and leave any ports prepared
on earlier links in the loop prepared), causing subsequent stream operations
to program banked registers into the currently active hardware bank?
[Severity: High]
Also, what happens to the per-port lane assignments and transport parameters
modified by bus->compute_params() on preceding links when restore_params
rolls back m_rt->bus->params?
During _sdw_prepare_stream(), bus->compute_params() calls
sdw_compute_params() -> sdw_compute_bus_params(), which allocates multi-lane
bandwidth in bus->params.lane_used_bandwidth[] and sets non-zero lane numbers
on the slave and master port runtimes:
if (m_lane > 0) {
/* Set Peripheral lanes */
list_for_each_entry(s_rt, &m_rt->slave_rt_list, m_rt_node) {
slave_prop = &s_rt->slave->prop;
for (l = 1; l < SDW_MAX_LANES; l++) {
if (slave_prop->lane_maps[l] == m_lane) {
list_for_each_entry(s_p_rt, &s_rt->port_list, port_node) {
s_p_rt->lane = l;
...
}
break;
}
}
}
...
list_for_each_entry(m_p_rt, &m_rt->port_list, port_node) {
m_p_rt->lane = m_lane;
}
}
It then calls _sdw_compute_port_params(), which updates p_rt->transport_params
across the ports on that bus.
When a subsequent step or link in _sdw_prepare_stream() fails, restoring
m_rt->bus->params = m_rt->params_backup reverts
bus->params.lane_used_bandwidth[] and bus->params.curr_dr_freq, but leaves
s_p_rt->lane, m_p_rt->lane, and p_rt->transport_params modified.
If the stream is later deprepared in _sdw_deprepare_stream():
list_for_each_entry(p_rt, &m_rt->port_list, port_node) {
if (!p_rt->lane)
continue;
bandwidth = m_rt->stream->params.rate * hweight32(p_rt->ch_mask) *
m_rt->stream->params.bps;
multi_lane_bandwidth += bandwidth;
bus->params.lane_used_bandwidth[p_rt->lane] -= bandwidth;
if (!bus->params.lane_used_bandwidth[p_rt->lane])
p_rt->lane = 0;
}
won't seeing a non-zero p_rt->lane after bus->params.lane_used_bandwidth[]
was rolled back underflow bus->params.lane_used_bandwidth[p_rt->lane] and
skip releasing multi_lane_bandwidth from bus->params.bandwidth, or cause
sdw_compute_group_params() and _sdw_compute_port_params() to skip the ports
when bus->params.lane_used_bandwidth[p_rt->lane] is zero?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261102060437.824814-1-yung-chuan.liao@linux.intel.com?part=2
prev parent reply other threads:[~2026-11-02 6:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-02 6:04 [PATCH 0/2] soundwire: Fix bandwidth leak in multi-link aggregation failure Bard Liao
2026-11-02 6:04 ` [PATCH 1/2] soundwire: move lane bandwidth into bus params Bard Liao
2026-11-02 6:16 ` sashiko-bot
2026-11-02 6:04 ` [PATCH 2/2] soundwire: stream: Fix bandwidth leak in multi-link aggregation failure Bard Liao
2026-11-02 6:16 ` 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-192944@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yung-chuan.liao@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox