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 for Android: free password hash cracker in your pocket

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

Message-ID: <20557448-d6d2-7584-e2ac-c46d337e1778@samsung.com>
Date:   Mon, 17 Feb 2020 15:36:51 +0100
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Jerome Brunet <jbrunet@...libre.com>,
        Mark Brown <broonie@...nel.org>
Cc:     alsa-devel@...a-project.org, Liam Girdwood <lgirdwood@...il.com>,
        linux-kernel@...r.kernel.org,
        linux-rpi-kernel <linux-rpi-kernel@...ts.infradead.org>
Subject: Re: Applied "ASoC: core: ensure component names are unique" to the
 asoc tree

Hi Jerome,

On 17.02.2020 14:18, Jerome Brunet wrote:
> On Mon 17 Feb 2020 at 13:13, Marek Szyprowski <m.szyprowski@...sung.com> wrote:
>> On 14.02.2020 21:56, Mark Brown 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
>>>
>>>   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>
>> This patch landed in today's linux-next and I've noticed that it breaks
>> registration of VC4 DRM driver on Raspberry Pi3 boards (I've compiled
>> kernel from bcm2835_defconfig):
> I think I have an idea about what is going on. (good catch in the defer BTW)
>
> 1) Funny to see that the vc4-hdmi already registers several (3) ASoC
> components. It must have had warning about the debugfs entry before this patch.

Okay, right, before this patch there is a warning from debugfs I've 
missed (debugfs was not enabled in bcm2835_defconfig):

raspberrypi-firmware soc:firmware: Attached to firmware from 2019-07-09 
14:40
raspberrypi-clk raspberrypi-clk: CPU frequency range: min 600000000, max 
1200000000
debugfs: Directory '3f902000.hdmi' with parent 'vc4-hdmi' already present!
vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok
vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops)
vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops)
vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops)
vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops)
vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops)
vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops)
vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops)
vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops)

> 2) Let say that vc4 hdmi driver defers after the registration of the 2nd
> component (/drivers/gpu/drm/vc4/vc4-hdmi.c:1082). The devm callback of
> the 2nd component will run first and call
> snd_soc_unregister_component(). The catch is that this function
> unregisters all the components registered by the linux device so far.
>
> 3) Then the devm callback of the dma_engine will run
> snd_dmaengine_pcm_unregister()
> (sound/soc/soc-generic-dmaengine-pcm.c:466) and the lookup will not find
> the component dmaengine component since it is already unregistered. The
> function bails out and dmaengine_pcm_release_chan() is not run.
>
> 4) Next time the hdmi driver tries to probe, the it will fail to
> allocate the DMA channel because the sysfs entry already exists.
>
> I would suspect that any driver doing:
> 1) devm_snd_dmaengine_pcm_register()
> 2) devm_snd_soc_register_component()
> could be exposed to this issue, even before this patch.
> I don't really get is triggering the issue in this change.
>
> Maybe it would be better if the devm callback of
> devm_snd_soc_register_component() unregistered only the related component.

 > ...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland