kernel oops on ICL when removing sof-pci-dev after failed firmware boot #945
Comments
plbossart
added a commit
to plbossart/sound
that referenced
this issue
May 14, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: thesofproject#945 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
plbossart
added a commit
that referenced
this issue
May 15, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: #945 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
bardliao
pushed a commit
that referenced
this issue
May 16, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: #945 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
|
@plbossart this issue is already fixed by #946? |
|
yes, we can close this. |
plbossart
added a commit
to plbossart/sound
that referenced
this issue
May 21, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: thesofproject#945 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
plbossart
added a commit
that referenced
this issue
May 24, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: #945 Fixes: c16211d ("ASoC: SOF: Add Sound Open Firmware driver core") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
plbossart
added a commit
that referenced
this issue
May 24, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: #945 Fixes: c16211d ("ASoC: SOF: Add Sound Open Firmware driver core") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
jason77-wang
pushed a commit
to jason77-wang/oem
that referenced
this issue
May 28, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: thesofproject/linux#945 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
jason77-wang
pushed a commit
to jason77-wang/oem
that referenced
this issue
Jun 1, 2019
BugLink: https://bugs.launchpad.net/bugs/1826181 In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: thesofproject/linux#945 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> (cherry picked from commit cbdcbcd38cc6f420241ed8e781e98605836e5c95 git://github.com/thesofproject/linux.git) Signed-off-by: Hui Wang <hui.wang@canonical.com>
plbossart
added a commit
that referenced
this issue
Jun 3, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: #945 Fixes: c16211d ("ASoC: SOF: Add Sound Open Firmware driver core") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> (cherry picked from commit 0bce512)
jason77-wang
pushed a commit
to jason77-wang/oem
that referenced
this issue
Jun 18, 2019
BugLink: https://bugs.launchpad.net/bugs/1826181 In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: thesofproject/linux#945 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> (cherry picked from commit cbdcbcd38cc6f420241ed8e781e98605836e5c95 git://github.com/thesofproject/linux.git) Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
jason77-wang
pushed a commit
to jason77-wang/oem
that referenced
this issue
Jun 24, 2019
BugLink: https://bugs.launchpad.net/bugs/1826181 In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: thesofproject/linux#945 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> (cherry picked from commit cbdcbcd38cc6f420241ed8e781e98605836e5c95 git://github.com/thesofproject/linux.git) Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
sathyap-chrome
pushed a commit
to sathyap-chrome/linux
that referenced
this issue
Jun 25, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: thesofproject#945 Fixes: c16211d ("ASoC: SOF: Add Sound Open Firmware driver core") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> (cherry picked from commit 0bce512 git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next) BUG=b:134688240 TEST=Test Audio use cases for CML with full SOF patch series applied. Change-Id: I78bb4807ee8534269ea04f4bc238a4a9975b2678 Signed-off-by: Ap, Kamal <kamal.ap@intel.corp-partner.google.com>
gs0622
pushed a commit
to gs0622/linux
that referenced
this issue
Jun 25, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: thesofproject#945 Fixes: c16211d ("ASoC: SOF: Add Sound Open Firmware driver core") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
fcicq
pushed a commit
to fcicq/chromiumos-third_party-kernel
that referenced
this issue
Jun 29, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: thesofproject/linux#945 Fixes: c16211d ("ASoC: SOF: Add Sound Open Firmware driver core") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> (cherry picked from commit 0bce512 git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next) BUG=b:134688240 TEST=Test Audio use cases for CML with full SOF patch series applied. Signed-off-by: Ap, Kamal <kamal.ap@intel.corp-partner.google.com>
jason77-wang
pushed a commit
to jason77-wang/oem
that referenced
this issue
Jul 5, 2019
BugLink: https://bugs.launchpad.net/bugs/1826181 In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: thesofproject/linux#945 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> (cherry picked from commit cbdcbcd38cc6f420241ed8e781e98605836e5c95 git://github.com/thesofproject/linux.git) Signed-off-by: Hui Wang <hui.wang@canonical.com> Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
cujomalainey
pushed a commit
to cujomalainey/linux
that referenced
this issue
Jul 9, 2019
In some configurations, it's a requirement to split the probe in two, with a second part handled in a workqueue (e.g. for HDMI support which depends on the DRM modules). SOF already handles these configurations but the error flow is incorrect. When an error occurs in the workqueue, the probe has technically already completed. If we release the resources on errors, this generates kernel oops/use-after-free when the resources are released a second time on module removal. GitHub issue: thesofproject#945 Fixes: c16211d ("ASoC: SOF: Add Sound Open Firmware driver core") Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org> (cherry picked from commit 0bce512) BUG=b:135490563 TEST=Test Audio use cases for GLK with full SOF patch series applied. Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
More issues with bad error handling. In this case the firmware boot issue is expected but that shouldn't lead to a kernel bug.
The text was updated successfully, but these errors were encountered: