linux-kernel - Re: Applied "ASoC: core: ensure component names are unique" to the asoc tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1jblpvraho.fsf@starbuckisacylon.baylibre.com>
Date:   Tue, 18 Feb 2020 19:55:31 +0100
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     alsa-devel@...a-project.org, Liam Girdwood <lgirdwood@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: Applied "ASoC: core: ensure component names are unique" to the asoc tree


On Fri 14 Feb 2020 at 21:56, Mark Brown <broonie@...nel.org> wrote:

> The patch
>
>    ASoC: core: ensure component names are unique
>
> has been applied to the asoc tree at
>
>    https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.  
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark

Hi Mark,

Short Version:
After looking at the problem reported by Marek, I think the best course
of action for now is to revert b2354e4009a7 ("ASoC: core: ensure component names are unique")
while working on a solution. It might take some time.

Longer Version:

1) Multiple components :
I found out that in fact it is common for linux devices to register
multiple components. For most, it is a combination of the dmaengine
generic and the actual device component, but other register more
component. Ex:
- vc4-hdmi
- atmel-classd
- atmel-pdmic
- cros-ec-codec
- mtXXXX-afe-pcm
I suspect these trigger the debugfs warning
Even dummy register two components :D

All devices using devm_snd_dmaengine_pcm_register() and
devm_snd_soc_register_component() are exposed to clean-up issue in case
of deferral. That's because snd_soc_unregister_component() unregisters
all the components registered the device. I suppose there might be other
problems when using the devm API with this function.

2) Fixed component names:
Several card driver assume the component name is the device name and
won't query the actual component name or node. Ex:
- sun4i-codec
- omap-hdmi
- vc4-hdmi
- sof-nocodec

So changing the way ASoC generate the component names might break these
cards. It gets tricky because the same cards driver might register
multiple component themselves, like vc4-hdmi.

>
> From b2354e4009a773c00054b964d937e1b81cb92078 Mon Sep 17 00:00:00 2001
> From: Jerome Brunet <jbrunet@...libre.com>
> Date: Fri, 14 Feb 2020 14:47:04 +0100
> Subject: [PATCH] ASoC: core: ensure component names are unique
>
> Make sure each ASoC component is registered with a unique name.
> The component is derived from the device name. If a device registers more
> than one component, the component names will be the same.
>
> This usually brings up a warning about the debugfs directory creation of
> the component since directory already exists.
>
> In such case, start numbering the component of the device so the names
> don't collide anymore.
>
> Signed-off-by: Jerome Brunet <jbrunet@...libre.com>
> Link: https://lore.kernel.org/r/20200214134704.342501-1-jbrunet@baylibre.com
> Signed-off-by: Mark Brown <broonie@...nel.org>
> ---
>  sound/soc/soc-core.c | 29 ++++++++++++++++++++++++++++-
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index 03b87427faa7..6a58a8f6e3c4 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -2446,6 +2446,33 @@ static int snd_soc_register_dais(struct snd_soc_component *component,
>  	return ret;
>  }
>  
> +static char *snd_soc_component_unique_name(struct device *dev,
> +					   struct snd_soc_component *component)
> +{
> +	struct snd_soc_component *pos;
> +	int count = 0;
> +	char *name, *unique;
> +
> +	name = fmt_single_name(dev, &component->id);
> +	if (!name)
> +		return name;
> +
> +	/* Count the number of components registred by the device */
> +	for_each_component(pos) {
> +		if (dev == pos->dev)
> +			count++;
> +	}
> +
> +	/* Keep naming as it is for the 1st component */
> +	if (!count)
> +		return name;
> +
> +	unique = devm_kasprintf(dev, GFP_KERNEL, "%s-%d", name, count);
> +	devm_kfree(dev, name);
> +
> +	return unique;
> +}
> +
>  static int snd_soc_component_initialize(struct snd_soc_component *component,
>  	const struct snd_soc_component_driver *driver, struct device *dev)
>  {
> @@ -2454,7 +2481,7 @@ static int snd_soc_component_initialize(struct snd_soc_component *component,
>  	INIT_LIST_HEAD(&component->card_list);
>  	mutex_init(&component->io_mutex);
>  
> -	component->name = fmt_single_name(dev, &component->id);
> +	component->name = snd_soc_component_unique_name(dev, component);
>  	if (!component->name) {
>  		dev_err(dev, "ASoC: Failed to allocate name\n");
>  		return -ENOMEM;