All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Matthias Reichl <hias@horus.com>, Mark Brown <broonie@kernel.org>,
	rohkumar@qti.qualcomm.com, alsa-devel@alsa-project.org,
	bgoswami@codeaurora.org, vinod.koul@linaro.org,
	lgirdwood@gmail.com, plai@codeaurora.org,
	linux-kernel@vger.kernel.org, tiwai@suse.com,
	Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	srinivas.kandagatla@linaro.org,
	Rohit kumar <rohitkr@codeaurora.org>,
	asishb@codeaurora.org, Ajit Pandey <ajitp@codeaurora.org>,
	Curtis Malainey <cujomalainey@chromium.org>
Subject: Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component
Date: Fri, 18 Jan 2019 17:02:08 -0600	[thread overview]
Message-ID: <044d59ba-094e-727d-14a9-6ebfc54cbbf4@linux.intel.com> (raw)
In-Reply-To: <af2e9555-444f-7c40-865b-347f3db8fa76@linux.intel.com>


On 1/15/19 3:16 PM, Pierre-Louis Bossart wrote:
>
>>> Beyond the fact that the platform_name seems to be totally useless,
>>> additional tests show that the patch ('ASoC: soc-core: defer card probe
>>> until all component is added to list') adds a new restriction which
>>> contradicts existing error checks.
>>>
>>> None of the Intel machine drivers set the dailink "cpu_name" field 
>>> but use
>>> the "cpu_dai_name" field instead. This was perfectly legit as 
>>> documented by
>>> the code at the end of soc_init_dai_link()
>> This should be fixed by the patch
>> "ASoC: core: Don't defer probe on optional, NULL components" which Mark
>> already applied to his tree. See
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2019-January/144323.html 
>>
>
> Ah yes, I missed this patch while I was debugging. Indeed this fixes 
> the problem and my devices work again with Mark's for-next branch. 
> Thanks Matthias!

This PROBE_DEFER support actually breaks the topology override that 
we've been relying on for SOF (and which has been in Mark's branch for 
some time now). This override helps us reuse machine drivers between 
legacy and SOF-based solutions.

With the current code, the tests in soc_register_card() complain that 
the platform_name can't be tied to a component and stop the card 
registration, but that's mainly because the tests are done before the 
topology overrides are done in soc_check_tplg_fes(). Moving 
soc_check_tplg_fes() from soc_instantiate_card() to an earlier time in 
soc_register_card() works-around the problem but looks quite invasive 
(mutex lock, etc).

There is also a second problem where we seem to have a memory management 
issue root caused to the change in snd_soc_init_platform() added by 
09ac6a817bd6 ('ASoC: soc-core: fix init platform memory handling')

The code does this

static int snd_soc_init_platform(struct snd_soc_card *card,
                  struct snd_soc_dai_link *dai_link)
{
     struct snd_soc_dai_link_component *platform = dai_link->platform;


     /* convert Legacy platform link */
     if (!platform || dai_link->legacy_platform) {
         platform = devm_kzalloc(card->dev,
                 sizeof(struct snd_soc_dai_link_component),
                 GFP_KERNEL);
         if (!platform)
             return -ENOMEM;

         dai_link->platform      = platform;
         dai_link->legacy_platform = 1;

This last assignment guarantees that memory will be allocated every time 
this function is called, and whatever overrides are done later will 
themselves be overridden by the new allocation. I am not sure what the 
intent was here, Curtis can you please double-check?

Details, test code and logs are available here: 
https://github.com/thesofproject/linux/issues/565

Have a nice week-end everyone, that's it for me until Tuesday.

-Pierre

  parent reply	other threads:[~2019-01-18 23:02 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-11  8:14 [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component Rohit kumar
2019-01-11 15:44 ` [alsa-devel] " Pierre-Louis Bossart
2019-01-11 21:49   ` Pierre-Louis Bossart
2019-01-12  6:07     ` Rohit kumar
2019-01-14 15:40       ` [alsa-devel] " Liam Girdwood
2019-01-15  0:06     ` Mark Brown
2019-01-15  3:08       ` Pierre-Louis Bossart
2019-01-15 19:35       ` [alsa-devel] " Pierre-Louis Bossart
2019-01-15 21:07         ` Mark Brown
2019-01-15 21:11         ` Matthias Reichl
2019-01-15 21:16           ` [alsa-devel] " Pierre-Louis Bossart
2019-01-15 21:41             ` Mark Brown
2019-01-15 21:48               ` [alsa-devel] " Matthias Reichl
2019-01-18 23:02             ` Pierre-Louis Bossart [this message]
2019-01-19  1:12               ` Curtis Malainey
2019-01-19  1:15                 ` [alsa-devel] " Curtis Malainey
2019-01-21 18:30                   ` Mark Brown
2019-01-22 20:11                   ` Pierre-Louis Bossart
2019-01-23  1:36                     ` [alsa-devel] " Curtis Malainey
2019-01-23  2:01                       ` Pierre-Louis Bossart
2019-01-24 18:44                         ` Mark Brown
2019-01-24 19:07                           ` [alsa-devel] " Pierre-Louis Bossart
2019-01-24 19:26                             ` Mark Brown
2019-01-25  1:32                               ` Curtis Malainey
2019-01-21 19:17               ` Mark Brown
2019-01-14 23:26 ` 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=044d59ba-094e-727d-14a9-6ebfc54cbbf4@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=ajitp@codeaurora.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=asishb@codeaurora.org \
    --cc=bgoswami@codeaurora.org \
    --cc=broonie@kernel.org \
    --cc=cujomalainey@chromium.org \
    --cc=hias@horus.com \
    --cc=lgirdwood@gmail.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=plai@codeaurora.org \
    --cc=rohitkr@codeaurora.org \
    --cc=rohkumar@qti.qualcomm.com \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=tiwai@suse.com \
    --cc=vinod.koul@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.