From: Cezary Rojewski <cezary.rojewski@intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Takashi Iwai <tiwai@suse.com>
Subject: Re: [RFC] soc_pcm_open: error path behavior change since v5.6
Date: Fri, 4 Sep 2020 11:35:30 +0200 [thread overview]
Message-ID: <f9a67925-046c-69d4-bc55-5d5e24d75425@intel.com> (raw)
In-Reply-To: <20200903131633.GA4771@sirena.org.uk>
On 2020-09-03 3:16 PM, Mark Brown wrote:
> On Thu, Sep 03, 2020 at 10:31:35AM +0200, Cezary Rojewski wrote:
>
>> Some time ago negative-tests found out that behavior of soc_pcm_open has
>> changed, quite sure this might be a regression hence my email. Till v5.6
>> soc_pcm_open was invoking ::shutdown() for cpu_dai in error path only if
>> ::startup() succeeded first (label: 'out'). After addition of commit:
>
> Please don't invent new notation that nobody else uses, it just makes
> your messages harder to read.
>
>> Should dai's ::shutdown() be introducing some kind of state-check from now
>> on? - similarly to how developers deal with some of the core pcm operations
>> e.g.: ::prepare() (as it may get invoked multiple times in a row so check is
>> there to prevent redundancy).
>
> If there are stateful things it's probably better to do that from a
> robustness point of view whatever is going on.
>
>> Or, perhaps behavior change should be reverted with ::shutdown() routine
>> again being called only after successful ::startup()?
>
> IIRC part of the thinking there was that we were getting the keeping
> track part of things wrong and sometimes missing things that should be
> being shut down in error paths. Anything that tries to stop extra calls
> would need to be very clearly robust and easily maintainable.
>
I'm sorry if my explanation was somewhat lackluster. In fact, thread's
name is misleading too -> regression sincec v5.7, not v5.6. Comparison
of code pieces found below should make it clearer:
v5.6 soc_pcm_open:
https://elixir.bootlin.com/linux/v5.6.19/source/sound/soc/soc-pcm.c#L534
static int soc_pcm_open(struct snd_pcm_substream *substream)
{
(...)
/* startup the audio subsystem */
ret = snd_soc_dai_startup(cpu_dai, substream);
if (ret < 0) {
dev_err(cpu_dai->dev, "ASoC: can't open interface %s: %d\n",
cpu_dai->name, ret);
goto out;
}
ret = soc_pcm_components_open(substream, &component);
if (ret < 0)
goto component_err;
for_each_rtd_codec_dai(rtd, i, codec_dai) {
ret = snd_soc_dai_startup(codec_dai, substream);
if (ret < 0) {
dev_err(codec_dai->dev,
"ASoC: can't open codec %s: %d\n",
codec_dai->name, ret);
goto codec_dai_err;
}
(...)
codec_dai_err:
for_each_rtd_codec_dai_rollback(rtd, i, codec_dai)
snd_soc_dai_shutdown(codec_dai, substream);
component_err:
soc_pcm_components_close(substream, component);
snd_soc_dai_shutdown(cpu_dai, substream);
out:
mutex_unlock(&rtd->card->pcm_mutex);
-
Now the equivalent from newer kernel e.g. v5.8:
https://elixir.bootlin.com/linux/v5.8.6/source/sound/soc/soc-pcm.c#L711
static int soc_pcm_open(struct snd_pcm_substream *substream)
{
(...)
/* startup the audio subsystem */
for_each_rtd_dais(rtd, i, dai) {
ret = snd_soc_dai_startup(dai, substream);
if (ret < 0) {
dev_err(dai->dev,
"ASoC: can't open DAI %s: %d\n",
dai->name, ret);
goto config_err;
}
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
dai->tx_mask = 0;
else
dai->rx_mask = 0;
}
(...)
config_err:
for_each_rtd_dais(rtd, i, dai)
snd_soc_dai_shutdown(dai, substream);
-
Let's assume we have 10 dais. In newer kernels, if snd_soc_dai_startup()
fails at i=5, error path will attempt to perform snd_soc_dai_shutdown()
for all dais (all 10) regardless if respective dai was opened or not.
This is a clear behavior change when compared to v5.6 where cpu_dai was
cleaned-up only if it was previously started successfully. Due to usage
of for_each_rtd_codec_dai_rollback macro, the same applies to codec_dais.
Czarek
next prev parent reply other threads:[~2020-09-04 9:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-03 8:31 [RFC] soc_pcm_open: error path behavior change since v5.6 Cezary Rojewski
2020-09-03 13:16 ` Mark Brown
2020-09-04 9:35 ` Cezary Rojewski [this message]
2020-09-06 23:11 ` Kuninori Morimoto
2020-09-04 0:01 ` Kuninori Morimoto
2020-09-04 9:25 ` Mark Brown
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=f9a67925-046c-69d4-bc55-5d5e24d75425@intel.com \
--to=cezary.rojewski@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=pierre-louis.bossart@linux.intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox