linux-kernel - Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of

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: <d1e41ed2-da7c-b46c-bc6d-64cf3e536771@nvidia.com>
Date:   Tue, 8 Jan 2019 12:03:25 +0000
From:   Jon Hunter <jonathanh@...dia.com>
To:     Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
CC:     Mark Brown <broonie@...nel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        <linux-tegra@...r.kernel.org>, Matthias Reichl <hias@...us.com>,
        <alsa-devel@...a-project.org>,
        Marcel Ziswiler <marcel.ziswiler@...adex.com>,
        Takashi Iwai <tiwai@...e.com>, <linux-kernel@...r.kernel.org>,
        Marcel Ziswiler <marcel@...wiler.com>
Subject: Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs.
 of_node assignement


On 08/01/2019 10:50, Jon Hunter wrote:
> Hi Kuninori,
> 
> On 08/01/2019 02:25, Kuninori Morimoto wrote:
>>
>> Hi Jon
>>
>>> I have been looking at this again recently. I see this issue occurring
>>> all the time when the sound drivers are built as kernel modules and
>>> probing the sound card is deferred until the codec driver has been loaded.
>>>
>>> Commit daecf46ee0e5 ("ASoC: soc-core: use snd_soc_dai_link_component for
>>> platform") appears to introduce the problem because now we allocate the
>>> 'snd_soc_dai_link_component' structure for the platform we attempt to
>>> register the soundcard but we never clear the freed pointer on failure.
>>> Therefore, we only actually allocate it the first time. There is no easy
>>> way to clear this pointer for the memory allocated because this is done
>>> before the dai-links have been added to the list of dai-links for the
>>> soundcard.
>>>
>>> I don't see an easy solution that will be 100% robust unless you do opt
>>> for copying all the dai-link info from the platform (but this is
>>> probably not a trivial fix).
>>>
>>> Do you envision a fix any time soon, or should we be updating all the
>>> machine drivers to populate the platform snd_soc_dai_link_component so
>>> that it is handled by the machine drivers are not the core?
>>
>> Thank you for pointing it.
>> Indeed it is mess.
>> I think coping info is nice idea,
>> but it is not easy so far, and it uses much memory...
>>
>> I didn't test this, but can below patch solve your issue ?
> 
> I will give it a try and let you know.

Yes so this does workaround the problem. However, per my previous
comments, I would like to explore whether it is necessary to allocate
the platform link component or if it can be static.

Cheers
Jon

-- 
nvpublic