From: Tzung-Bi Shih <tzungbi@google.com> To: Marek Szyprowski <m.szyprowski@samsung.com> Cc: ALSA development <alsa-devel@alsa-project.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>, Mark Brown <broonie@kernel.org>, Sylwester Nawrocki <s.nawrocki@samsung.com>, Dylan Reid <dgreid@google.com>, Jimmy Cheng-Yi Chiang <cychiang@google.com>, Krzysztof Kozlowski <krzk@kernel.org>, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Subject: Re: [PATCH 2/2] ASoC: max98090: fix lockdep warning Date: Thu, 9 Jan 2020 18:59:39 +0800 [thread overview] Message-ID: <CA+Px+wWVhZn+UrX04bGMnR8J0XeR0+Oy1r0DD4Spm+i1WPZKqQ@mail.gmail.com> (raw) In-Reply-To: <CA+Px+wXkFE5b_8bLz7-c95TvEdqHGD5s-XKRYMVr40xQkqTWxQ@mail.gmail.com> On Thu, Jan 9, 2020 at 1:36 PM Tzung-Bi Shih <tzungbi@google.com> wrote: > On Wed, Jan 8, 2020 at 7:50 PM Marek Szyprowski > <m.szyprowski@samsung.com> wrote: > > This fixes the following lockdep warning observed on Exynos4412-based > > Odroid U3 board: > > ====================================================== > > -> #1 (&card->controls_rwsem){++++}: > > snd_ctl_add_replace+0x3c/0x84 > > dapm_create_or_share_kcontrol+0x24c/0x2e0 > > snd_soc_dapm_new_widgets+0x308/0x594 > > snd_soc_bind_card+0x80c/0xad4 > > devm_snd_soc_register_card+0x34/0x6c > > odroid_audio_probe+0x288/0x34c > > platform_drv_probe+0x6c/0xa4 I noticed the stack is a little different than the last time (odroid_audio_probe vs. asoc_simple_probe). Did you use the same machine to test? > asoc_simple_probe+0x244/0x4a0 > platform_drv_probe+0x6c/0xa4 (https://mailman.alsa-project.org/pipermail/alsa-devel/2019-December/160142.html) > I would like to spend some time to find the root cause. It would be a > little challenging though (I have no real runtime to test...). After a few hours of study, I failed to find the reason to cause the possible circular locking. And would need more of your input. Followed the information provided in the message (https://mailman.alsa-project.org/pipermail/alsa-devel/2019-December/160535.html). As the message said "snd_soc_of_get_dai_link_codecs() return -EPROBE_DEFER". The snd_soc_of_get_dai_link_codecs( ) is before devm_snd_soc_register_card( ), and I didn't find any side effects in odroid_audio_probe( ). Only a very minor issue: snd_soc_of_put_dai_link_codecs(codec_link) will be called twice. One in snd_soc_of_get_dai_link_codecs( ) when return -EPROBE_DEFER; another one is under the label "err_put_cpu_dai". (https://elixir.bootlin.com/linux/v5.5-rc5/source/sound/soc/samsung/odroid.c#L328) The code doesn't generate any side effects because of snd_soc_of_put_dai_link_codecs( )'s robustness. Another minor thing: odroid_card_dais is not immutable but odroid_audio_probe( ) would try to modify it (https://elixir.bootlin.com/linux/v5.5-rc5/source/sound/soc/samsung/odroid.c#L295). Again, I don't think it would produce any troubles. I guess no machine would have multiple sound cards, share the same machine driver, and unbind/bind in runtime. > It is weird: userspace should not see things (e.g. no controlC0) until > snd_card_register( ). (based on today's broonie/sound.git/for-next) I would like to provide you more information about this statement to help you find further information. When userspace can see the control device? Ideally, snd_soc_bind_card( ) -> snd_card_register( ) -> snd_device_register_all( ) -> __snd_device_register( ) -> snd_ctl_dev_register( ) -> snd_register_device( ). If you look at the calling stack of possible circular locking, snd_soc_dapm_new_widgets( ) is before snd_card_register( ). That's why we think userspace should not see control devices (i.e. controlC0, controlC1, ...) and should not be able to set mixer control via ioctl( ). As this may not directly be related to the issue, could you share the init script of alsactl in your system? Does it follow the convention? (i.e. sound card is ready when receives controlC* changed event in udev rule 78-sound-card.rules) > 6. when userspace init scripts (alsactl) enumerates devices (https://mailman.alsa-project.org/pipermail/alsa-devel/2019-December/160535.html)
WARNING: multiple messages have this Message-ID (diff)
From: Tzung-Bi Shih <tzungbi@google.com> To: Marek Szyprowski <m.szyprowski@samsung.com> Cc: ALSA development <alsa-devel@alsa-project.org>, Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>, Jimmy Cheng-Yi Chiang <cychiang@google.com>, Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Krzysztof Kozlowski <krzk@kernel.org>, Mark Brown <broonie@kernel.org>, Sylwester Nawrocki <s.nawrocki@samsung.com>, Dylan Reid <dgreid@google.com> Subject: Re: [alsa-devel] [PATCH 2/2] ASoC: max98090: fix lockdep warning Date: Thu, 9 Jan 2020 18:59:39 +0800 [thread overview] Message-ID: <CA+Px+wWVhZn+UrX04bGMnR8J0XeR0+Oy1r0DD4Spm+i1WPZKqQ@mail.gmail.com> (raw) In-Reply-To: <CA+Px+wXkFE5b_8bLz7-c95TvEdqHGD5s-XKRYMVr40xQkqTWxQ@mail.gmail.com> On Thu, Jan 9, 2020 at 1:36 PM Tzung-Bi Shih <tzungbi@google.com> wrote: > On Wed, Jan 8, 2020 at 7:50 PM Marek Szyprowski > <m.szyprowski@samsung.com> wrote: > > This fixes the following lockdep warning observed on Exynos4412-based > > Odroid U3 board: > > ====================================================== > > -> #1 (&card->controls_rwsem){++++}: > > snd_ctl_add_replace+0x3c/0x84 > > dapm_create_or_share_kcontrol+0x24c/0x2e0 > > snd_soc_dapm_new_widgets+0x308/0x594 > > snd_soc_bind_card+0x80c/0xad4 > > devm_snd_soc_register_card+0x34/0x6c > > odroid_audio_probe+0x288/0x34c > > platform_drv_probe+0x6c/0xa4 I noticed the stack is a little different than the last time (odroid_audio_probe vs. asoc_simple_probe). Did you use the same machine to test? > asoc_simple_probe+0x244/0x4a0 > platform_drv_probe+0x6c/0xa4 (https://mailman.alsa-project.org/pipermail/alsa-devel/2019-December/160142.html) > I would like to spend some time to find the root cause. It would be a > little challenging though (I have no real runtime to test...). After a few hours of study, I failed to find the reason to cause the possible circular locking. And would need more of your input. Followed the information provided in the message (https://mailman.alsa-project.org/pipermail/alsa-devel/2019-December/160535.html). As the message said "snd_soc_of_get_dai_link_codecs() return -EPROBE_DEFER". The snd_soc_of_get_dai_link_codecs( ) is before devm_snd_soc_register_card( ), and I didn't find any side effects in odroid_audio_probe( ). Only a very minor issue: snd_soc_of_put_dai_link_codecs(codec_link) will be called twice. One in snd_soc_of_get_dai_link_codecs( ) when return -EPROBE_DEFER; another one is under the label "err_put_cpu_dai". (https://elixir.bootlin.com/linux/v5.5-rc5/source/sound/soc/samsung/odroid.c#L328) The code doesn't generate any side effects because of snd_soc_of_put_dai_link_codecs( )'s robustness. Another minor thing: odroid_card_dais is not immutable but odroid_audio_probe( ) would try to modify it (https://elixir.bootlin.com/linux/v5.5-rc5/source/sound/soc/samsung/odroid.c#L295). Again, I don't think it would produce any troubles. I guess no machine would have multiple sound cards, share the same machine driver, and unbind/bind in runtime. > It is weird: userspace should not see things (e.g. no controlC0) until > snd_card_register( ). (based on today's broonie/sound.git/for-next) I would like to provide you more information about this statement to help you find further information. When userspace can see the control device? Ideally, snd_soc_bind_card( ) -> snd_card_register( ) -> snd_device_register_all( ) -> __snd_device_register( ) -> snd_ctl_dev_register( ) -> snd_register_device( ). If you look at the calling stack of possible circular locking, snd_soc_dapm_new_widgets( ) is before snd_card_register( ). That's why we think userspace should not see control devices (i.e. controlC0, controlC1, ...) and should not be able to set mixer control via ioctl( ). As this may not directly be related to the issue, could you share the init script of alsactl in your system? Does it follow the convention? (i.e. sound card is ready when receives controlC* changed event in udev rule 78-sound-card.rules) > 6. when userspace init scripts (alsactl) enumerates devices (https://mailman.alsa-project.org/pipermail/alsa-devel/2019-December/160535.html) _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2020-01-09 10:59 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <CGME20200108115027eucas1p2abcd40e359e993e5b471229b02b69fc3@eucas1p2.samsung.com> 2020-01-08 11:50 ` [PATCH 1/2] ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double() Marek Szyprowski 2020-01-08 11:50 ` [alsa-devel] " Marek Szyprowski [not found] ` <CGME20200108115027eucas1p1d3645ba53703780679c662921efbca78@eucas1p1.samsung.com> 2020-01-08 11:50 ` [PATCH 2/2] ASoC: max98090: fix lockdep warning Marek Szyprowski 2020-01-08 11:50 ` [alsa-devel] " Marek Szyprowski 2020-01-09 5:36 ` Tzung-Bi Shih 2020-01-09 5:36 ` [alsa-devel] " Tzung-Bi Shih 2020-01-09 10:59 ` Tzung-Bi Shih [this message] 2020-01-09 10:59 ` Tzung-Bi Shih 2020-01-09 11:09 ` Marek Szyprowski 2020-01-09 11:09 ` [alsa-devel] " Marek Szyprowski 2020-01-10 1:05 ` Tzung-Bi Shih 2020-01-10 1:05 ` [alsa-devel] " Tzung-Bi Shih 2020-01-09 21:29 ` Applied "ASoC: max98090: fix lockdep warning" to the asoc tree Mark Brown 2020-01-09 21:29 ` [alsa-devel] " Mark Brown 2020-01-09 5:11 ` [PATCH 1/2] ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double() Tzung-Bi Shih 2020-01-09 5:11 ` [alsa-devel] " Tzung-Bi Shih 2020-01-09 21:29 ` Applied "ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double()" to the asoc tree Mark Brown 2020-01-09 21:29 ` [alsa-devel] " Mark Brown 2020-01-09 21:29 ` Mark Brown 2020-01-09 21:29 ` [alsa-devel] " Mark Brown 2020-01-10 9:02 ` Marek Szyprowski 2020-01-10 9:02 ` [alsa-devel] " Marek Szyprowski 2020-01-10 13:25 ` Mark Brown 2020-01-10 13:25 ` [alsa-devel] " 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=CA+Px+wWVhZn+UrX04bGMnR8J0XeR0+Oy1r0DD4Spm+i1WPZKqQ@mail.gmail.com \ --to=tzungbi@google.com \ --cc=alsa-devel@alsa-project.org \ --cc=b.zolnierkie@samsung.com \ --cc=broonie@kernel.org \ --cc=cychiang@google.com \ --cc=dgreid@google.com \ --cc=krzk@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=m.szyprowski@samsung.com \ --cc=s.nawrocki@samsung.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: linkBe 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.