Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Cezary Rojewski <cezary.rojewski@intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org,
	pierre-louis.bossart@linux.intel.com, tiwai@suse.com,
	hdegoede@redhat.com, broonie@kernel.org,
	amadeuszx.slawinski@linux.intel.com
Subject: Re: [PATCH 1/9] ALSA: hda: Do not unset preset when cleaning up codec
Date: Tue, 12 Jul 2022 11:42:56 +0200	[thread overview]
Message-ID: <8bdd56fc-de6b-381e-24f5-5d2c28e337f7@intel.com> (raw)
In-Reply-To: <877d4jsppp.wl-tiwai@suse.de>

On 2022-07-11 4:12 PM, Takashi Iwai wrote:
> On Mon, 11 Jul 2022 10:25:17 +0200,
> Cezary Rojewski wrote:

...

>> avs-driver i.e. the bus driver takes responsibility for the codec
>> device only. There is no real probe(), just the device creation and
>> initialization of its fields. The rest is handled by the component
>> driver (sound/soc/hda.c). If this field is cleared and the test is
>> limited to reloading HDAudio codec module alone, we get a
>> panic. Something similar to the stack found below my message.
>>
>> In regard to the other question - are presets freed at all? It seems
>> all of them are part of the static device-driver matching list. If so,
>> the pointer is always valid.
> 
> When the codec driver is unbound and the module is unloaded, the whole
> objects and symbols are gone.


hda_codec_driver_remove() won't get even called when soc-card is being 
unbound so everything is still here.

>> [  136.827856] RIP: 0010:hda_codec_probe+0x16c/0x560 [snd_soc_hda_codec]

>> [  136.828568] Call Trace:
>> [  136.828593]  <TASK>
>> [  136.828628]  snd_soc_component_probe+0x3a/0x60 [snd_soc_core]
>> [  136.828981]  soc_probe_component+0x276/0x4a0 [snd_soc_core]
>> [  136.829274]  snd_soc_bind_card+0x819/0x13d0 [snd_soc_core]
>> [  136.829560]  ? __kasan_slab_alloc+0x32/0x90
>> [  136.829614]  snd_soc_register_card+0x24e/0x260 [snd_soc_core]
>> [  136.829900]  devm_snd_soc_register_card+0x48/0x90 [snd_soc_core]
>> [  136.830204]  avs_hdaudio_probe+0x298/0x2c0 [snd_soc_avs_hdaudio]

>> (...)
> 
> Hmm, in the Oops above, at which moment,
> snd_hda_codec_cleanup_for_unbind() is called via which function?
> Is it the unload of HD-audio codec driver during the probe of AVS
> HD-audio?
> 
> The preset is assigned to the given HD-audio device object for the
> attached codec driver.  Once after the codec driver gets unbound, you
> must not access to this codec driver's methods any longer, hence we
> clear the preset field.
> 
> So I wonder how the access to the codec->preset happens after the
> codec unbind.


Test scenario:
- enumerate avs-driver stack on machine with HDAudio codec present
- rmmod snd_soc_avs_hdaudio // just the machine board driver i.e. 
soc-card driver
- modprobe snd_soc_avs_hdaudio
 >>> panic <<<

snd_hda_codec_cleanup_for_unbind() is called in more places than just 
HDAudio codec driver's probe() and remove(). It's also called whenever 
HDAudio codec soc-component is being removed. Relevant part of the stack 
showing when does the cleanup function get called during rmmod:

[  220.549349]  snd_hda_codec_cleanup_for_unbind+0x25/0x451 [snd_hda_codec]
[  220.549536]  ? dump_stack_lvl+0x45/0x49
[  220.549568]  hda_codec_remove.cold+0x14/0x138 [snd_soc_hda_codec]
[  220.549609]  snd_soc_component_remove+0x34/0x40 [snd_soc_core]
[  220.549942]  soc_remove_component+0x113/0x120 [snd_soc_core]
[  220.550249]  soc_cleanup_card_resources+0x1a7/0x4a0 [snd_soc_core]
[  220.550561]  snd_soc_unbind_card+0x9e/0x190 [snd_soc_core]
[  220.550885]  snd_soc_unregister_card+0x28/0x80 [snd_soc_core]
[  220.551193]  devm_card_release+0x1d/0x20 [snd_soc_core]
[  220.551527]  release_nodes+0x73/0x170
[  220.551549]  ? preempt_count_sub+0x18/0xc0
[  220.551576]  devres_release_all+0x10a/0x150
[  220.551600]  ? devres_remove_group+0x260/0x260
[  220.551630]  device_unbind_cleanup+0x14/0xd0
[  220.551656]  device_release_driver_internal+0x146/0x1d0
[  220.551688]  driver_detach+0x81/0xf0
[  220.551716]  bus_remove_driver+0xae/0x170
[  220.551743]  driver_unregister+0x4d/0x70
[  220.551770]  platform_driver_unregister+0x12/0x20
[  220.551799]  avs_hdaudio_driver_exit+0x10/0x12 [snd_soc_avs_hdaudio]


Regards,
Czarek

  reply	other threads:[~2022-07-12  9:44 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-06 12:02 [PATCH 0/9] ALSA: hda: Codec-reload bug fixes and cleanups Cezary Rojewski
2022-07-06 12:02 ` [PATCH 1/9] ALSA: hda: Do not unset preset when cleaning up codec Cezary Rojewski
2022-07-09 16:34   ` Takashi Iwai
2022-07-11  8:25     ` Cezary Rojewski
2022-07-11 14:12       ` Takashi Iwai
2022-07-12  9:42         ` Cezary Rojewski [this message]
2022-07-12 10:46           ` Takashi Iwai
2022-07-12 10:58             ` Cezary Rojewski
2022-07-15 14:55               ` Takashi Iwai
2023-01-17 14:45                 ` Cezary Rojewski
2023-01-17 14:51                   ` Takashi Iwai
2022-07-06 12:02 ` [PATCH 2/9] ALSA: hda: Fix null-ptr-deref when i915 fails and hdmi is denylisted Cezary Rojewski
2022-07-06 12:02 ` [PATCH 3/9] ALSA: hda: Make device usage_count consistent across subsequent probing Cezary Rojewski
2022-07-06 12:02 ` [PATCH 4/9] ALSA: hda: Fix put_device() inconsistency in error path Cezary Rojewski
2022-07-06 12:02 ` [PATCH 5/9] ALSA: hda: Skip event processing for unregistered codecs Cezary Rojewski
2022-07-09 16:47   ` Takashi Iwai
2022-07-15 14:27     ` Takashi Iwai
2022-07-06 12:02 ` [PATCH 6/9] ALSA: hda: Fix page fault in snd_hda_codec_shutdown() Cezary Rojewski
2022-07-15 18:16   ` Pierre-Louis Bossart
2022-07-15 18:23     ` Takashi Iwai
2022-07-17 10:05       ` Cezary Rojewski
2022-07-06 12:02 ` [PATCH 7/9] ALSA: hda: Reset all SIE bits in INTCTL Cezary Rojewski
2022-07-06 12:02 ` [PATCH 8/9] ALSA: hda: Remove unused macro definition Cezary Rojewski
2022-07-06 12:02 ` [PATCH 9/9] ALSA: hda/realtek: Remove redundant init_hook() in alc_default_init() Cezary Rojewski
2022-07-09 16:46   ` Takashi Iwai
2022-07-11  8:12     ` Cezary Rojewski
2022-07-09 16:50 ` [PATCH 0/9] ALSA: hda: Codec-reload bug fixes and cleanups Takashi Iwai

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=8bdd56fc-de6b-381e-24f5-5d2c28e337f7@intel.com \
    --to=cezary.rojewski@intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=tiwai@suse.com \
    --cc=tiwai@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox