From: Takashi Iwai <tiwai@suse.de>
To: Cezary Rojewski <cezary.rojewski@intel.com>
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] ALSA: hda: Do not unset preset when cleaning up codec
Date: Wed, 18 Jan 2023 13:32:33 +0100 [thread overview]
Message-ID: <87h6wot44e.wl-tiwai@suse.de> (raw)
In-Reply-To: <22911d1c-02d0-e70d-63eb-44328d131c30@intel.com>
On Wed, 18 Jan 2023 13:04:05 +0100,
Cezary Rojewski wrote:
>
> On 2023-01-17 5:01 PM, Takashi Iwai wrote:
>
> ...
>
> >> This is a continuation of a discussion that begun in the middle of 2022
> >> [1] and was part of a larger series addressing several HDAudio topics.
> >>
> >> Single rmmod on ASoC's codec driver module is enough to cause a panic.
> >> Given our results, no regression shows up with modprobe/rmmod on
> >> snd_hda_intel side with this patch applied.
> >
> > I think one possible regression by this change would be the case you
> > reload another codec driver. With keeping codec->preset, it's still
> > thought as if already matched, and a wrong one could be used.
> >
> > And, this would be nothing but a leak of the possibly freed address.
> > After hda_codec_driver_remove(), card->preset may point to an already
> > freed address.
> >
> > So, just removing isn't right. It has to be cleared somewhere
> > instead, e.g. in hda_bind.c.
> >
> > But, one thing I'm still concerned is that your comment about the call
> > without the card binding. Do you mean that the
> > snd_hda_codec_cleanup_for_unbind() may be called even if codec->card
> > isn't set?
>
> One proposition would be to add line:
> codec->preset = NULL;
>
> after both invocations of snd_hda_codec_cleanup_for_unbind() in
> hda_codec_driver_probe/remove() in sound/pci/hda/hda_bind.c.
Yes, that's what I meant, too.
> In regard to your last question - no, cleanup is only called either in
> component->probe()'s error path or in component->remove() once
> snd_hda_codec_device_new() succeeds and thus, codec->card points to a
> valid sound card.
>
> What I meant by my comment, is that removal of any components of an
> ASoC sound card will cause all other components to have their
> ->remove() op called too. Let's say I unload snd_soc_avs_hdaudio
> module without unloading snd_soc_avs. As bus (snd_soc_avs) owns the
> codecs, its platform component->remove() gets called right after codec
> component->remove() but the actual devices are still present in the
> system even with the sound card module (snd_soc_avs_hdaudio) unloaded.
OK, then the snd_hda_codec object itself is kept bound on the bus,
hence the call of snd_hda_codec_cleanup_for_unbind() is somehow
inappropriate. The function could be renamed for avoid
misunderstanding.
thanks,
Takashi
prev parent reply other threads:[~2023-01-18 12:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 15:47 [PATCH] ALSA: hda: Do not unset preset when cleaning up codec Cezary Rojewski
2023-01-17 15:48 ` Pierre-Louis Bossart
2023-01-18 11:38 ` Cezary Rojewski
2023-01-18 11:47 ` Cezary Rojewski
2023-01-17 16:01 ` Takashi Iwai
2023-01-18 12:04 ` Cezary Rojewski
2023-01-18 12:32 ` Takashi Iwai [this message]
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=87h6wot44e.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=hdegoede@redhat.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=tiwai@suse.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: 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.