Message ID | 20230119143235.1159814-1-cezary.rojewski@intel.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [v2] ALSA: hda: Do not unset preset when cleaning up codec | expand |
On Thu, 19 Jan 2023 15:32:35 +0100, Cezary Rojewski wrote: > > Several functions that take part in codec's initialization and removal > are re-used by ASoC codec drivers implementations. Drivers mimic the > behavior of hda_codec_driver_probe/remove() found in > sound/pci/hda/hda_bind.c with their component->probe/remove() instead. > > One of the reasons for that is the expectation of > snd_hda_codec_device_new() to receive a valid pointer to an instance of > struct snd_card. This expectation can be met only once sound card > components probing commences. > > As ASoC sound card may be unbound without codec device being actually > removed from the system, unsetting ->preset in > snd_hda_codec_cleanup_for_unbind() interferes with module unload -> load > scenario causing null-ptr-deref. Preset is assigned only once, during > device/driver matching whereas ASoC codec driver's module reloading may > occur several times throughout the lifetime of an audio stack. > > Suggested-by: Takashi Iwai <tiwai@suse.com> > Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> > --- > > Changes in v2: > - relocated the operation to routines found in hda_bind.c rather than > just removing it from the cleanup function > > > 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. > > [1]: https://lore.kernel.org/alsa-devel/20220706120230.427296-2-cezary.rojewski@intel.com/ Thanks, applied now. Takashi
diff --git a/sound/pci/hda/hda_bind.c b/sound/pci/hda/hda_bind.c index 1a868dd9dc4b..890c2f7c33fc 100644 --- a/sound/pci/hda/hda_bind.c +++ b/sound/pci/hda/hda_bind.c @@ -144,6 +144,7 @@ static int hda_codec_driver_probe(struct device *dev) error: snd_hda_codec_cleanup_for_unbind(codec); + codec->preset = NULL; return err; } @@ -166,6 +167,7 @@ static int hda_codec_driver_remove(struct device *dev) if (codec->patch_ops.free) codec->patch_ops.free(codec); snd_hda_codec_cleanup_for_unbind(codec); + codec->preset = NULL; module_put(dev->driver->owner); return 0; } diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index edd653ece70d..ac1cc7c5290e 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -795,7 +795,6 @@ void snd_hda_codec_cleanup_for_unbind(struct hda_codec *codec) snd_array_free(&codec->cvt_setups); snd_array_free(&codec->spdif_out); snd_array_free(&codec->verbs); - codec->preset = NULL; codec->follower_dig_outs = NULL; codec->spdif_status_reset = 0; snd_array_free(&codec->mixers);
Several functions that take part in codec's initialization and removal are re-used by ASoC codec drivers implementations. Drivers mimic the behavior of hda_codec_driver_probe/remove() found in sound/pci/hda/hda_bind.c with their component->probe/remove() instead. One of the reasons for that is the expectation of snd_hda_codec_device_new() to receive a valid pointer to an instance of struct snd_card. This expectation can be met only once sound card components probing commences. As ASoC sound card may be unbound without codec device being actually removed from the system, unsetting ->preset in snd_hda_codec_cleanup_for_unbind() interferes with module unload -> load scenario causing null-ptr-deref. Preset is assigned only once, during device/driver matching whereas ASoC codec driver's module reloading may occur several times throughout the lifetime of an audio stack. Suggested-by: Takashi Iwai <tiwai@suse.com> Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com> --- Changes in v2: - relocated the operation to routines found in hda_bind.c rather than just removing it from the cleanup function 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. [1]: https://lore.kernel.org/alsa-devel/20220706120230.427296-2-cezary.rojewski@intel.com/ sound/pci/hda/hda_bind.c | 2 ++ sound/pci/hda/hda_codec.c | 1 - 2 files changed, 2 insertions(+), 1 deletion(-)