* [PATCH v8 1/3] kexec: Refactor kexec_in_progress into a function
2022-12-01 11:08 [PATCH v8 0/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace Ricardo Ribalda
@ 2022-12-01 11:08 ` Ricardo Ribalda
2022-12-01 11:08 ` [PATCH v8 2/3] freezer: refactor pm_freezing " Ricardo Ribalda
2022-12-01 11:08 ` [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace Ricardo Ribalda
2 siblings, 0 replies; 12+ messages in thread
From: Ricardo Ribalda @ 2022-12-01 11:08 UTC (permalink / raw)
To: Juergen Gross, Mark Brown, Chromeos Kdump, Daniel Baluta,
Christophe Leroy, Len Brown, Ard Biesheuvel, Ranjani Sridharan,
Rafael J. Wysocki, Boris Ostrovsky, Nicholas Piggin,
Michael Ellerman, Eric Biederman, Dave Hansen, Jaroslav Kysela,
Joel Fernandes, Liam Girdwood, Peter Ujfalusi, Pavel Machek,
Pierre-Louis Bossart, Kai Vehmanen, Steven Rostedt,
K. Y. Srinivasan, Ingo Molnar, Bjorn Helgaas, Dexuan Cui,
Takashi Iwai, H. Peter Anvin, Bard Liao, Haiyang Zhang, Wei Liu,
Thomas Gleixner, Borislav Petkov, x86
Cc: kexec, alsa-devel, Ricardo Ribalda, stable, sound-open-firmware,
linuxppc-dev, linux-hyperv, linux-pci, linux-pm, linux-kernel,
linux-efi, xen-devel
Drivers running .shutdown() might want to behave differently during
kexec.
Convert kexec_in_progress into a function and export it, so it can be
used by drivers that are either built-in or modules.
Cc: stable@vger.kernel.org
Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers in .shutdown")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
---
arch/powerpc/platforms/pseries/vio.c | 2 +-
arch/x86/kernel/cpu/mshyperv.c | 6 +++---
arch/x86/xen/enlighten_hvm.c | 2 +-
drivers/firmware/efi/efi.c | 2 +-
drivers/pci/pci-driver.c | 2 +-
include/linux/kexec.h | 5 ++---
kernel/kexec_core.c | 12 ++++++++++--
7 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/vio.c b/arch/powerpc/platforms/pseries/vio.c
index 00ecac2c205b..923f9a36b992 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -1289,7 +1289,7 @@ static void vio_bus_shutdown(struct device *dev)
viodrv = to_vio_driver(dev->driver);
if (viodrv->shutdown)
viodrv->shutdown(viodev);
- else if (kexec_in_progress)
+ else if (kexec_in_progress())
vio_bus_remove(dev);
}
}
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 831613959a92..f91f35206489 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -122,21 +122,21 @@ void hv_remove_crash_handler(void)
#ifdef CONFIG_KEXEC_CORE
static void hv_machine_shutdown(void)
{
- if (kexec_in_progress && hv_kexec_handler)
+ if (kexec_in_progress() && hv_kexec_handler)
hv_kexec_handler();
/*
* Call hv_cpu_die() on all the CPUs, otherwise later the hypervisor
* corrupts the old VP Assist Pages and can crash the kexec kernel.
*/
- if (kexec_in_progress && hyperv_init_cpuhp > 0)
+ if (kexec_in_progress() && hyperv_init_cpuhp > 0)
cpuhp_remove_state(hyperv_init_cpuhp);
/* The function calls stop_other_cpus(). */
native_machine_shutdown();
/* Disable the hypercall page when there is only 1 active CPU. */
- if (kexec_in_progress)
+ if (kexec_in_progress())
hyperv_cleanup();
}
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index c1cd28e915a3..769163833ffc 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -145,7 +145,7 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_xen_hvm_callback)
static void xen_hvm_shutdown(void)
{
native_machine_shutdown();
- if (kexec_in_progress)
+ if (kexec_in_progress())
xen_reboot(SHUTDOWN_soft_reset);
}
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index a46df5d1d094..608bc2146802 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -1040,7 +1040,7 @@ static int update_efi_random_seed(struct notifier_block *nb,
struct linux_efi_random_seed *seed;
u32 size = 0;
- if (!kexec_in_progress)
+ if (!kexec_in_progress())
return NOTIFY_DONE;
seed = memremap(efi_rng_seed, sizeof(*seed), MEMREMAP_WB);
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 107d77f3c846..23eeb7538b03 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -519,7 +519,7 @@ static void pci_device_shutdown(struct device *dev)
* If it is not a kexec reboot, firmware will hit the PCI
* devices with big hammer and stop their DMA any way.
*/
- if (kexec_in_progress && (pci_dev->current_state <= PCI_D3hot))
+ if (kexec_in_progress() && pci_dev->current_state <= PCI_D3hot)
pci_clear_master(pci_dev);
}
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 41a686996aaa..2ec0aec1a0de 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -423,8 +423,7 @@ extern int kexec_load_disabled;
#define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
KEXEC_FILE_NO_INITRAMFS)
-/* flag to track if kexec reboot is in progress */
-extern bool kexec_in_progress;
+bool kexec_in_progress(void);
int crash_shrink_memory(unsigned long new_size);
ssize_t crash_get_memory_size(void);
@@ -507,7 +506,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
static inline void crash_kexec(struct pt_regs *regs) { }
static inline int kexec_should_crash(struct task_struct *p) { return 0; }
static inline int kexec_crash_loaded(void) { return 0; }
-#define kexec_in_progress false
+static inline bool kexec_in_progress(void) { return false; }
#endif /* CONFIG_KEXEC_CORE */
#ifdef CONFIG_KEXEC_SIG
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index ca2743f9c634..4495d0fc28ae 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -52,8 +52,16 @@ atomic_t __kexec_lock = ATOMIC_INIT(0);
note_buf_t __percpu *crash_notes;
/* Flag to indicate we are going to kexec a new kernel */
-bool kexec_in_progress = false;
+static bool kexec_in_progress_internal;
+/**
+ * kexec_in_progress - Check if the system is going to kexec
+ */
+bool kexec_in_progress(void)
+{
+ return kexec_in_progress_internal;
+}
+EXPORT_SYMBOL(kexec_in_progress);
/* Location of the reserved area for the crash kernel */
struct resource crashk_res = {
@@ -1175,7 +1183,7 @@ int kernel_kexec(void)
} else
#endif
{
- kexec_in_progress = true;
+ kexec_in_progress_internal = true;
kernel_restart_prepare("kexec reboot");
migrate_to_reboot_cpu();
--
2.39.0.rc0.267.gcb52ba06e7-goog-b4-0.11.0-dev-696ae
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH v8 2/3] freezer: refactor pm_freezing into a function.
2022-12-01 11:08 [PATCH v8 0/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace Ricardo Ribalda
2022-12-01 11:08 ` [PATCH v8 1/3] kexec: Refactor kexec_in_progress into a function Ricardo Ribalda
@ 2022-12-01 11:08 ` Ricardo Ribalda
2022-12-02 17:47 ` Rafael J. Wysocki
2022-12-01 11:08 ` [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace Ricardo Ribalda
2 siblings, 1 reply; 12+ messages in thread
From: Ricardo Ribalda @ 2022-12-01 11:08 UTC (permalink / raw)
To: Juergen Gross, Mark Brown, Chromeos Kdump, Daniel Baluta,
Christophe Leroy, Len Brown, Ard Biesheuvel, Ranjani Sridharan,
Rafael J. Wysocki, Boris Ostrovsky, Nicholas Piggin,
Michael Ellerman, Eric Biederman, Dave Hansen, Jaroslav Kysela,
Joel Fernandes, Liam Girdwood, Peter Ujfalusi, Pavel Machek,
Pierre-Louis Bossart, Kai Vehmanen, Steven Rostedt,
K. Y. Srinivasan, Ingo Molnar, Bjorn Helgaas, Dexuan Cui,
Takashi Iwai, H. Peter Anvin, Bard Liao, Haiyang Zhang, Wei Liu,
Thomas Gleixner, Borislav Petkov, x86
Cc: kexec, alsa-devel, Ricardo Ribalda, stable, sound-open-firmware,
linuxppc-dev, linux-hyperv, linux-pci, linux-pm, linux-kernel,
linux-efi, xen-devel
Add a way to let the drivers know if the processes are frozen.
This is needed by drivers that are waiting for processes to end on their
shutdown path.
Convert pm_freezing into a function and export it, so it can be used by
drivers that are either built-in or modules.
Cc: stable@vger.kernel.org
Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers in .shutdown")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
sdad
---
include/linux/freezer.h | 3 ++-
kernel/freezer.c | 3 +--
kernel/power/process.c | 24 ++++++++++++++++++++----
3 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/include/linux/freezer.h b/include/linux/freezer.h
index b303472255be..3413c869d68b 100644
--- a/include/linux/freezer.h
+++ b/include/linux/freezer.h
@@ -13,7 +13,7 @@
#ifdef CONFIG_FREEZER
DECLARE_STATIC_KEY_FALSE(freezer_active);
-extern bool pm_freezing; /* PM freezing in effect */
+bool pm_freezing(void);
extern bool pm_nosig_freezing; /* PM nosig freezing in effect */
/*
@@ -80,6 +80,7 @@ static inline int freeze_processes(void) { return -ENOSYS; }
static inline int freeze_kernel_threads(void) { return -ENOSYS; }
static inline void thaw_processes(void) {}
static inline void thaw_kernel_threads(void) {}
+static inline bool pm_freezing(void) { return false; }
static inline bool try_to_freeze(void) { return false; }
diff --git a/kernel/freezer.c b/kernel/freezer.c
index 4fad0e6fca64..2d3530ebdb7e 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -20,7 +20,6 @@ EXPORT_SYMBOL(freezer_active);
* indicate whether PM freezing is in effect, protected by
* system_transition_mutex
*/
-bool pm_freezing;
bool pm_nosig_freezing;
/* protects freezing and frozen transitions */
@@ -46,7 +45,7 @@ bool freezing_slow_path(struct task_struct *p)
if (pm_nosig_freezing || cgroup_freezing(p))
return true;
- if (pm_freezing && !(p->flags & PF_KTHREAD))
+ if (pm_freezing() && !(p->flags & PF_KTHREAD))
return true;
return false;
diff --git a/kernel/power/process.c b/kernel/power/process.c
index ddd9988327fe..8a4d0e2c8c20 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -108,6 +108,22 @@ static int try_to_freeze_tasks(bool user_only)
return todo ? -EBUSY : 0;
}
+/*
+ * Indicate whether PM freezing is in effect, protected by
+ * system_transition_mutex.
+ */
+static bool pm_freezing_internal;
+
+/**
+ * pm_freezing - indicate whether PM freezing is in effect.
+ *
+ */
+bool pm_freezing(void)
+{
+ return pm_freezing_internal;
+}
+EXPORT_SYMBOL(pm_freezing);
+
/**
* freeze_processes - Signal user space processes to enter the refrigerator.
* The current thread will not be frozen. The same process that calls
@@ -126,12 +142,12 @@ int freeze_processes(void)
/* Make sure this task doesn't get frozen */
current->flags |= PF_SUSPEND_TASK;
- if (!pm_freezing)
+ if (!pm_freezing())
static_branch_inc(&freezer_active);
pm_wakeup_clear(0);
pr_info("Freezing user space processes ... ");
- pm_freezing = true;
+ pm_freezing_internal = true;
error = try_to_freeze_tasks(true);
if (!error) {
__usermodehelper_set_disable_depth(UMH_DISABLED);
@@ -187,9 +203,9 @@ void thaw_processes(void)
struct task_struct *curr = current;
trace_suspend_resume(TPS("thaw_processes"), 0, true);
- if (pm_freezing)
+ if (pm_freezing())
static_branch_dec(&freezer_active);
- pm_freezing = false;
+ pm_freezing_internal = false;
pm_nosig_freezing = false;
oom_killer_enable();
--
2.39.0.rc0.267.gcb52ba06e7-goog-b4-0.11.0-dev-696ae
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH v8 2/3] freezer: refactor pm_freezing into a function.
2022-12-01 11:08 ` [PATCH v8 2/3] freezer: refactor pm_freezing " Ricardo Ribalda
@ 2022-12-02 17:47 ` Rafael J. Wysocki
2022-12-05 12:05 ` Ricardo Ribalda
0 siblings, 1 reply; 12+ messages in thread
From: Rafael J. Wysocki @ 2022-12-02 17:47 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Juergen Gross, Mark Brown, Chromeos Kdump, Daniel Baluta,
Christophe Leroy, Len Brown, Ard Biesheuvel, Ranjani Sridharan,
Rafael J. Wysocki, Boris Ostrovsky, Nicholas Piggin,
Michael Ellerman, Eric Biederman, Dave Hansen, Jaroslav Kysela,
Joel Fernandes, Liam Girdwood, Peter Ujfalusi, Pavel Machek,
Pierre-Louis Bossart, Kai Vehmanen, Steven Rostedt,
K. Y. Srinivasan, Ingo Molnar, Bjorn Helgaas, Dexuan Cui,
Takashi Iwai, H. Peter Anvin, Bard Liao, Haiyang Zhang, Wei Liu,
Thomas Gleixner, Borislav Petkov, x86, kexec, alsa-devel, stable,
sound-open-firmware, linuxppc-dev, linux-hyperv, linux-pci,
linux-pm, linux-kernel, linux-efi, xen-devel
On Thu, Dec 1, 2022 at 12:08 PM Ricardo Ribalda <ribalda@chromium.org> wrote:
>
> Add a way to let the drivers know if the processes are frozen.
>
> This is needed by drivers that are waiting for processes to end on their
> shutdown path.
>
> Convert pm_freezing into a function and export it, so it can be used by
> drivers that are either built-in or modules.
>
> Cc: stable@vger.kernel.org
> Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers in .shutdown")
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Why can't you export the original pm_freezing variable and why is this
fixing anything?
> ---
> include/linux/freezer.h | 3 ++-
> kernel/freezer.c | 3 +--
> kernel/power/process.c | 24 ++++++++++++++++++++----
> 3 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> index b303472255be..3413c869d68b 100644
> --- a/include/linux/freezer.h
> +++ b/include/linux/freezer.h
> @@ -13,7 +13,7 @@
> #ifdef CONFIG_FREEZER
> DECLARE_STATIC_KEY_FALSE(freezer_active);
>
> -extern bool pm_freezing; /* PM freezing in effect */
> +bool pm_freezing(void);
> extern bool pm_nosig_freezing; /* PM nosig freezing in effect */
>
> /*
> @@ -80,6 +80,7 @@ static inline int freeze_processes(void) { return -ENOSYS; }
> static inline int freeze_kernel_threads(void) { return -ENOSYS; }
> static inline void thaw_processes(void) {}
> static inline void thaw_kernel_threads(void) {}
> +static inline bool pm_freezing(void) { return false; }
>
> static inline bool try_to_freeze(void) { return false; }
>
> diff --git a/kernel/freezer.c b/kernel/freezer.c
> index 4fad0e6fca64..2d3530ebdb7e 100644
> --- a/kernel/freezer.c
> +++ b/kernel/freezer.c
> @@ -20,7 +20,6 @@ EXPORT_SYMBOL(freezer_active);
> * indicate whether PM freezing is in effect, protected by
> * system_transition_mutex
> */
> -bool pm_freezing;
> bool pm_nosig_freezing;
>
> /* protects freezing and frozen transitions */
> @@ -46,7 +45,7 @@ bool freezing_slow_path(struct task_struct *p)
> if (pm_nosig_freezing || cgroup_freezing(p))
> return true;
>
> - if (pm_freezing && !(p->flags & PF_KTHREAD))
> + if (pm_freezing() && !(p->flags & PF_KTHREAD))
> return true;
>
> return false;
> diff --git a/kernel/power/process.c b/kernel/power/process.c
> index ddd9988327fe..8a4d0e2c8c20 100644
> --- a/kernel/power/process.c
> +++ b/kernel/power/process.c
> @@ -108,6 +108,22 @@ static int try_to_freeze_tasks(bool user_only)
> return todo ? -EBUSY : 0;
> }
>
> +/*
> + * Indicate whether PM freezing is in effect, protected by
> + * system_transition_mutex.
> + */
> +static bool pm_freezing_internal;
> +
> +/**
> + * pm_freezing - indicate whether PM freezing is in effect.
> + *
> + */
> +bool pm_freezing(void)
> +{
> + return pm_freezing_internal;
> +}
> +EXPORT_SYMBOL(pm_freezing);
Use EXPORT_SYMBOL_GPL() instead, please.
> +
> /**
> * freeze_processes - Signal user space processes to enter the refrigerator.
> * The current thread will not be frozen. The same process that calls
> @@ -126,12 +142,12 @@ int freeze_processes(void)
> /* Make sure this task doesn't get frozen */
> current->flags |= PF_SUSPEND_TASK;
>
> - if (!pm_freezing)
> + if (!pm_freezing())
> static_branch_inc(&freezer_active);
>
> pm_wakeup_clear(0);
> pr_info("Freezing user space processes ... ");
> - pm_freezing = true;
> + pm_freezing_internal = true;
> error = try_to_freeze_tasks(true);
> if (!error) {
> __usermodehelper_set_disable_depth(UMH_DISABLED);
> @@ -187,9 +203,9 @@ void thaw_processes(void)
> struct task_struct *curr = current;
>
> trace_suspend_resume(TPS("thaw_processes"), 0, true);
> - if (pm_freezing)
> + if (pm_freezing())
> static_branch_dec(&freezer_active);
> - pm_freezing = false;
> + pm_freezing_internal = false;
> pm_nosig_freezing = false;
>
> oom_killer_enable();
>
> --
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v8 2/3] freezer: refactor pm_freezing into a function.
2022-12-02 17:47 ` Rafael J. Wysocki
@ 2022-12-05 12:05 ` Ricardo Ribalda
0 siblings, 0 replies; 12+ messages in thread
From: Ricardo Ribalda @ 2022-12-05 12:05 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Juergen Gross, Mark Brown, Chromeos Kdump, Daniel Baluta,
Christophe Leroy, Len Brown, Ard Biesheuvel, Ranjani Sridharan,
Boris Ostrovsky, Nicholas Piggin, Michael Ellerman,
Eric Biederman, Dave Hansen, Jaroslav Kysela, Joel Fernandes,
Liam Girdwood, Peter Ujfalusi, Pavel Machek,
Pierre-Louis Bossart, Kai Vehmanen, Steven Rostedt,
K. Y. Srinivasan, Ingo Molnar, Bjorn Helgaas, Dexuan Cui,
Takashi Iwai, H. Peter Anvin, Bard Liao, Haiyang Zhang, Wei Liu,
Thomas Gleixner, Borislav Petkov, x86, kexec, alsa-devel, stable,
sound-open-firmware, linuxppc-dev, linux-hyperv, linux-pci,
linux-pm, linux-kernel, linux-efi, xen-devel
Hi Rafael
On Fri, 2 Dec 2022 at 18:48, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Dec 1, 2022 at 12:08 PM Ricardo Ribalda <ribalda@chromium.org> wrote:
> >
> > Add a way to let the drivers know if the processes are frozen.
> >
> > This is needed by drivers that are waiting for processes to end on their
> > shutdown path.
> >
> > Convert pm_freezing into a function and export it, so it can be used by
> > drivers that are either built-in or modules.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers in .shutdown")
> > Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
>
> Why can't you export the original pm_freezing variable and why is this
> fixing anything?
Because then any module will be able to modify the content of the variable.
The Fixes: is because the last patch on the set is doing a real fix.
If you only cherry-pick the last patch on a stable branch, the build
will fail. (Also, the zero-day builder complains)
Anyway, I think we can hold this patch for a bit. The snd people are
discussing if this the way to handle it, or if we should handle
.shutdown in a different way.
Thanks!
>
> > ---
> > include/linux/freezer.h | 3 ++-
> > kernel/freezer.c | 3 +--
> > kernel/power/process.c | 24 ++++++++++++++++++++----
> > 3 files changed, 23 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> > index b303472255be..3413c869d68b 100644
> > --- a/include/linux/freezer.h
> > +++ b/include/linux/freezer.h
> > @@ -13,7 +13,7 @@
> > #ifdef CONFIG_FREEZER
> > DECLARE_STATIC_KEY_FALSE(freezer_active);
> >
> > -extern bool pm_freezing; /* PM freezing in effect */
> > +bool pm_freezing(void);
> > extern bool pm_nosig_freezing; /* PM nosig freezing in effect */
> >
> > /*
> > @@ -80,6 +80,7 @@ static inline int freeze_processes(void) { return -ENOSYS; }
> > static inline int freeze_kernel_threads(void) { return -ENOSYS; }
> > static inline void thaw_processes(void) {}
> > static inline void thaw_kernel_threads(void) {}
> > +static inline bool pm_freezing(void) { return false; }
> >
> > static inline bool try_to_freeze(void) { return false; }
> >
> > diff --git a/kernel/freezer.c b/kernel/freezer.c
> > index 4fad0e6fca64..2d3530ebdb7e 100644
> > --- a/kernel/freezer.c
> > +++ b/kernel/freezer.c
> > @@ -20,7 +20,6 @@ EXPORT_SYMBOL(freezer_active);
> > * indicate whether PM freezing is in effect, protected by
> > * system_transition_mutex
> > */
> > -bool pm_freezing;
> > bool pm_nosig_freezing;
> >
> > /* protects freezing and frozen transitions */
> > @@ -46,7 +45,7 @@ bool freezing_slow_path(struct task_struct *p)
> > if (pm_nosig_freezing || cgroup_freezing(p))
> > return true;
> >
> > - if (pm_freezing && !(p->flags & PF_KTHREAD))
> > + if (pm_freezing() && !(p->flags & PF_KTHREAD))
> > return true;
> >
> > return false;
> > diff --git a/kernel/power/process.c b/kernel/power/process.c
> > index ddd9988327fe..8a4d0e2c8c20 100644
> > --- a/kernel/power/process.c
> > +++ b/kernel/power/process.c
> > @@ -108,6 +108,22 @@ static int try_to_freeze_tasks(bool user_only)
> > return todo ? -EBUSY : 0;
> > }
> >
> > +/*
> > + * Indicate whether PM freezing is in effect, protected by
> > + * system_transition_mutex.
> > + */
> > +static bool pm_freezing_internal;
> > +
> > +/**
> > + * pm_freezing - indicate whether PM freezing is in effect.
> > + *
> > + */
> > +bool pm_freezing(void)
> > +{
> > + return pm_freezing_internal;
> > +}
> > +EXPORT_SYMBOL(pm_freezing);
>
> Use EXPORT_SYMBOL_GPL() instead, please.
>
> > +
> > /**
> > * freeze_processes - Signal user space processes to enter the refrigerator.
> > * The current thread will not be frozen. The same process that calls
> > @@ -126,12 +142,12 @@ int freeze_processes(void)
> > /* Make sure this task doesn't get frozen */
> > current->flags |= PF_SUSPEND_TASK;
> >
> > - if (!pm_freezing)
> > + if (!pm_freezing())
> > static_branch_inc(&freezer_active);
> >
> > pm_wakeup_clear(0);
> > pr_info("Freezing user space processes ... ");
> > - pm_freezing = true;
> > + pm_freezing_internal = true;
> > error = try_to_freeze_tasks(true);
> > if (!error) {
> > __usermodehelper_set_disable_depth(UMH_DISABLED);
> > @@ -187,9 +203,9 @@ void thaw_processes(void)
> > struct task_struct *curr = current;
> >
> > trace_suspend_resume(TPS("thaw_processes"), 0, true);
> > - if (pm_freezing)
> > + if (pm_freezing())
> > static_branch_dec(&freezer_active);
> > - pm_freezing = false;
> > + pm_freezing_internal = false;
> > pm_nosig_freezing = false;
> >
> > oom_killer_enable();
> >
> > --
>
> --
> You received this message because you are subscribed to the Google Groups "Chromeos Kdump" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chromeos-kdump+unsubscribe@google.com.
> To view this discussion on the web, visit https://groups.google.com/a/google.com/d/msgid/chromeos-kdump/CAJZ5v0jbKSTQopEoXW9FpqDmAqp6Pn%3D-Om5QP2-7ocuGdq8R9w%40mail.gmail.com.
--
Ricardo Ribalda
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
2022-12-01 11:08 [PATCH v8 0/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace Ricardo Ribalda
2022-12-01 11:08 ` [PATCH v8 1/3] kexec: Refactor kexec_in_progress into a function Ricardo Ribalda
2022-12-01 11:08 ` [PATCH v8 2/3] freezer: refactor pm_freezing " Ricardo Ribalda
@ 2022-12-01 11:08 ` Ricardo Ribalda
2022-12-01 12:28 ` Oliver Neukum
2 siblings, 1 reply; 12+ messages in thread
From: Ricardo Ribalda @ 2022-12-01 11:08 UTC (permalink / raw)
To: Juergen Gross, Mark Brown, Chromeos Kdump, Daniel Baluta,
Christophe Leroy, Len Brown, Ard Biesheuvel, Ranjani Sridharan,
Rafael J. Wysocki, Boris Ostrovsky, Nicholas Piggin,
Michael Ellerman, Eric Biederman, Dave Hansen, Jaroslav Kysela,
Joel Fernandes, Liam Girdwood, Peter Ujfalusi, Pavel Machek,
Pierre-Louis Bossart, Kai Vehmanen, Steven Rostedt,
K. Y. Srinivasan, Ingo Molnar, Bjorn Helgaas, Dexuan Cui,
Takashi Iwai, H. Peter Anvin, Bard Liao, Haiyang Zhang, Wei Liu,
Thomas Gleixner, Borislav Petkov, x86
Cc: kexec, alsa-devel, Ricardo Ribalda, stable, sound-open-firmware,
linuxppc-dev, linux-hyperv, linux-pci, linux-pm, linux-kernel,
linux-efi, xen-devel
If we are shutting down due to kexec and the userspace is frozen, the
system will stall forever waiting for userspace to complete.
Do not wait for the clients to complete in that case.
This fixes:
[ 84.943749] Freezing user space processes ... (elapsed 0.111 seconds) done.
[ 246.784446] INFO: task kexec-lite:5123 blocked for more than 122 seconds.
[ 246.819035] Call Trace:
[ 246.821782] <TASK>
[ 246.824186] __schedule+0x5f9/0x1263
[ 246.828231] schedule+0x87/0xc5
[ 246.831779] snd_card_disconnect_sync+0xb5/0x127
...
[ 246.889249] snd_sof_device_shutdown+0xb4/0x150
[ 246.899317] pci_device_shutdown+0x37/0x61
[ 246.903990] device_shutdown+0x14c/0x1d6
[ 246.908391] kernel_kexec+0x45/0xb9
And:
[ 246.893222] INFO: task kexec-lite:4891 blocked for more than 122 seconds.
[ 246.927709] Call Trace:
[ 246.930461] <TASK>
[ 246.932819] __schedule+0x5f9/0x1263
[ 246.936855] ? fsnotify_grab_connector+0x5c/0x70
[ 246.942045] schedule+0x87/0xc5
[ 246.945567] schedule_timeout+0x49/0xf3
[ 246.949877] wait_for_completion+0x86/0xe8
[ 246.954463] snd_card_free+0x68/0x89
...
[ 247.001080] platform_device_unregister+0x12/0x35
Cc: stable@vger.kernel.org
Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers in .shutdown")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
---
sound/soc/sof/core.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c
index 3e6141d03770..9587b6a85103 100644
--- a/sound/soc/sof/core.c
+++ b/sound/soc/sof/core.c
@@ -9,6 +9,8 @@
//
#include <linux/firmware.h>
+#include <linux/kexec.h>
+#include <linux/freezer.h>
#include <linux/module.h>
#include <sound/soc.h>
#include <sound/sof.h>
@@ -484,9 +486,10 @@ int snd_sof_device_shutdown(struct device *dev)
* make sure clients and machine driver(s) are unregistered to force
* all userspace devices to be closed prior to the DSP shutdown sequence
*/
- sof_unregister_clients(sdev);
-
- snd_sof_machine_unregister(sdev, pdata);
+ if (!(kexec_in_progress() && pm_freezing())) {
+ sof_unregister_clients(sdev);
+ snd_sof_machine_unregister(sdev, pdata);
+ }
if (sdev->fw_state == SOF_FW_BOOT_COMPLETE)
return snd_sof_shutdown(sdev);
--
2.39.0.rc0.267.gcb52ba06e7-goog-b4-0.11.0-dev-696ae
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
2022-12-01 11:08 ` [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace Ricardo Ribalda
@ 2022-12-01 12:28 ` Oliver Neukum
2022-12-01 13:03 ` Ricardo Ribalda
0 siblings, 1 reply; 12+ messages in thread
From: Oliver Neukum @ 2022-12-01 12:28 UTC (permalink / raw)
To: Ricardo Ribalda, Juergen Gross, Mark Brown, Chromeos Kdump,
Daniel Baluta, Christophe Leroy, Len Brown, Ard Biesheuvel,
Ranjani Sridharan, Rafael J. Wysocki, Boris Ostrovsky,
Nicholas Piggin, Michael Ellerman, Eric Biederman, Dave Hansen,
Jaroslav Kysela, Joel Fernandes, Liam Girdwood, Peter Ujfalusi,
Pavel Machek, Pierre-Louis Bossart, Kai Vehmanen, Steven Rostedt,
K. Y. Srinivasan, Ingo Molnar, Bjorn Helgaas, Dexuan Cui,
Takashi Iwai, H. Peter Anvin, Bard Liao, Haiyang Zhang, Wei Liu,
Thomas Gleixner, Borislav Petkov, x86
Cc: kexec, alsa-devel, stable, sound-open-firmware, linuxppc-dev,
linux-hyperv, linux-pci, linux-pm, linux-kernel, linux-efi,
xen-devel
On 01.12.22 12:08, Ricardo Ribalda wrote:
> If we are shutting down due to kexec and the userspace is frozen, the
> system will stall forever waiting for userspace to complete.
>
> Do not wait for the clients to complete in that case.
Hi,
I am afraid I have to state that this approach is bad in every case,
not just this corner case. It basically means that user space can stall
the kernel for an arbitrary amount of time. And we cannot have that.
Regards
Oliver
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
2022-12-01 12:28 ` Oliver Neukum
@ 2022-12-01 13:03 ` Ricardo Ribalda
2022-12-01 13:22 ` Oliver Neukum
0 siblings, 1 reply; 12+ messages in thread
From: Ricardo Ribalda @ 2022-12-01 13:03 UTC (permalink / raw)
To: Oliver Neukum
Cc: Juergen Gross, Mark Brown, Chromeos Kdump, Daniel Baluta,
Christophe Leroy, Len Brown, Ard Biesheuvel, Ranjani Sridharan,
Rafael J. Wysocki, Boris Ostrovsky, Nicholas Piggin,
Michael Ellerman, Eric Biederman, Dave Hansen, Jaroslav Kysela,
Joel Fernandes, Liam Girdwood, Peter Ujfalusi, Pavel Machek,
Pierre-Louis Bossart, Kai Vehmanen, Steven Rostedt,
K. Y. Srinivasan, Ingo Molnar, Bjorn Helgaas, Dexuan Cui,
Takashi Iwai, H. Peter Anvin, Bard Liao, Haiyang Zhang, Wei Liu,
Thomas Gleixner, Borislav Petkov, x86, kexec, alsa-devel, stable,
sound-open-firmware, linuxppc-dev, linux-hyperv, linux-pci,
linux-pm, linux-kernel, linux-efi, xen-devel
Hi Oliver
Thanks for your review
On Thu, 1 Dec 2022 at 13:29, Oliver Neukum <oneukum@suse.com> wrote:
>
> On 01.12.22 12:08, Ricardo Ribalda wrote:
> > If we are shutting down due to kexec and the userspace is frozen, the
> > system will stall forever waiting for userspace to complete.
> >
> > Do not wait for the clients to complete in that case.
>
> Hi,
>
> I am afraid I have to state that this approach is bad in every case,
> not just this corner case. It basically means that user space can stall
> the kernel for an arbitrary amount of time. And we cannot have that.
>
> Regards
> Oliver
This patchset does not modify this behaviour. It simply fixes the
stall for kexec().
The patch that introduced the stall:
83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
was sent as a generalised version of:
https://github.com/thesofproject/linux/pull/3388
AFAIK, we would need a similar patch for every single board.... which
I am not sure it is doable in a reasonable timeframe.
On the meantime this seems like a decent compromises. Yes, a
miss-behaving userspace can still stall during suspend, but that was
not introduced in this patch.
Regards!
>
--
Ricardo Ribalda
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
2022-12-01 13:03 ` Ricardo Ribalda
@ 2022-12-01 13:22 ` Oliver Neukum
2022-12-01 13:34 ` Ricardo Ribalda
2022-12-01 13:38 ` Takashi Iwai
0 siblings, 2 replies; 12+ messages in thread
From: Oliver Neukum @ 2022-12-01 13:22 UTC (permalink / raw)
To: Ricardo Ribalda, Oliver Neukum
Cc: Juergen Gross, Mark Brown, Chromeos Kdump, Daniel Baluta,
Christophe Leroy, Len Brown, Ard Biesheuvel, Ranjani Sridharan,
Rafael J. Wysocki, Boris Ostrovsky, Nicholas Piggin,
Michael Ellerman, Eric Biederman, Dave Hansen, Jaroslav Kysela,
Joel Fernandes, Liam Girdwood, Peter Ujfalusi, Pavel Machek,
Pierre-Louis Bossart, Kai Vehmanen, Steven Rostedt,
K. Y. Srinivasan, Ingo Molnar, Bjorn Helgaas, Dexuan Cui,
Takashi Iwai, H. Peter Anvin, Bard Liao, Haiyang Zhang, Wei Liu,
Thomas Gleixner, Borislav Petkov, x86, kexec, alsa-devel, stable,
sound-open-firmware, linuxppc-dev, linux-hyperv, linux-pci,
linux-pm, linux-kernel, linux-efi, xen-devel
On 01.12.22 14:03, Ricardo Ribalda wrote:
Hi,
> This patchset does not modify this behaviour. It simply fixes the
> stall for kexec().
>
> The patch that introduced the stall:
> 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
> in .shutdown")
That patch is problematic. I would go as far as saying that
it needs to be reverted.
> was sent as a generalised version of:
> https://github.com/thesofproject/linux/pull/3388
>
> AFAIK, we would need a similar patch for every single board.... which
> I am not sure it is doable in a reasonable timeframe.
>
> On the meantime this seems like a decent compromises. Yes, a
> miss-behaving userspace can still stall during suspend, but that was
> not introduced in this patch.
Well, I mean if you know what wrong then I'd say at least return to
a sanely broken state.
The whole approach is wrong. You need to be able to deal with user
space talking to removed devices by returning an error and keeping
the resources association with the open file allocated until
user space calls close()
Regards
Oliver
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
2022-12-01 13:22 ` Oliver Neukum
@ 2022-12-01 13:34 ` Ricardo Ribalda
2022-12-09 11:53 ` Kai Vehmanen
2022-12-01 13:38 ` Takashi Iwai
1 sibling, 1 reply; 12+ messages in thread
From: Ricardo Ribalda @ 2022-12-01 13:34 UTC (permalink / raw)
To: Oliver Neukum
Cc: Juergen Gross, Mark Brown, Chromeos Kdump, Daniel Baluta,
Christophe Leroy, Len Brown, Ard Biesheuvel, Ranjani Sridharan,
Rafael J. Wysocki, Boris Ostrovsky, Nicholas Piggin,
Michael Ellerman, Eric Biederman, Dave Hansen, Jaroslav Kysela,
Joel Fernandes, Liam Girdwood, Peter Ujfalusi, Pavel Machek,
Pierre-Louis Bossart, Kai Vehmanen, Steven Rostedt,
K. Y. Srinivasan, Ingo Molnar, Bjorn Helgaas, Dexuan Cui,
Takashi Iwai, H. Peter Anvin, Bard Liao, Haiyang Zhang, Wei Liu,
Thomas Gleixner, Borislav Petkov, x86, kexec, alsa-devel, stable,
sound-open-firmware, linuxppc-dev, linux-hyperv, linux-pci,
linux-pm, linux-kernel, linux-efi, xen-devel
Hi Oliver
On Thu, 1 Dec 2022 at 14:22, 'Oliver Neukum' via Chromeos Kdump
<chromeos-kdump@google.com> wrote:
>
> On 01.12.22 14:03, Ricardo Ribalda wrote:
>
> Hi,
>
> > This patchset does not modify this behaviour. It simply fixes the
> > stall for kexec().
> >
> > The patch that introduced the stall:
> > 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
> > in .shutdown")
>
> That patch is problematic. I would go as far as saying that
> it needs to be reverted.
>
It fixes a real issue. We have not had any complaints until we tried
to kexec in the platform.
I wont recommend reverting it until we have an alternative implementation.
kexec is far less common than suspend/reboot.
> > was sent as a generalised version of:
> > https://github.com/thesofproject/linux/pull/3388
> >
> > AFAIK, we would need a similar patch for every single board.... which
> > I am not sure it is doable in a reasonable timeframe.
> >
> > On the meantime this seems like a decent compromises. Yes, a
> > miss-behaving userspace can still stall during suspend, but that was
> > not introduced in this patch.
>
> Well, I mean if you know what wrong then I'd say at least return to
> a sanely broken state.
>
> The whole approach is wrong. You need to be able to deal with user
> space talking to removed devices by returning an error and keeping
> the resources association with the open file allocated until
> user space calls close()
In general, the whole shutdown is broken for all the subsystems ;).
It is a complicated issue. Users handling fds, devices with DMAs in
the middle of an operation, dma fences....
Unfortunately I am not that familiar with the sound subsystem to make
a proper patch for this.
>
> Regards
> Oliver
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "Chromeos Kdump" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chromeos-kdump+unsubscribe@google.com.
> To view this discussion on the web, visit https://groups.google.com/a/google.com/d/msgid/chromeos-kdump/d3730d1d-6f92-700a-06c4-0e0a35e270b0%40suse.com.
--
Ricardo Ribalda
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
2022-12-01 13:34 ` Ricardo Ribalda
@ 2022-12-09 11:53 ` Kai Vehmanen
0 siblings, 0 replies; 12+ messages in thread
From: Kai Vehmanen @ 2022-12-09 11:53 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Oliver Neukum, Juergen Gross, Mark Brown, Chromeos Kdump,
Daniel Baluta, Christophe Leroy, Len Brown, Ard Biesheuvel,
Ranjani Sridharan, Rafael J. Wysocki, Boris Ostrovsky,
Nicholas Piggin, Michael Ellerman, Eric Biederman, Dave Hansen,
Jaroslav Kysela, Joel Fernandes, Liam Girdwood, Peter Ujfalusi,
Pavel Machek, Pierre-Louis Bossart, Kai Vehmanen, Steven Rostedt,
K. Y. Srinivasan, Ingo Molnar, Bjorn Helgaas, Dexuan Cui,
Takashi Iwai, H. Peter Anvin, Bard Liao, Haiyang Zhang, Wei Liu,
Thomas Gleixner, Borislav Petkov, x86, kexec, Alsa-devel, stable,
sound-open-firmware, linuxppc-dev, linux-hyperv, linux-pci,
linux-pm, linux-kernel, linux-efi, xen-devel
Hi,
On Thu, 1 Dec 2022, Ricardo Ribalda wrote:
> On Thu, 1 Dec 2022 at 14:22, 'Oliver Neukum' via Chromeos Kdump <chromeos-kdump@google.com> wrote:
> >
> > On 01.12.22 14:03, Ricardo Ribalda wrote:
> > > This patchset does not modify this behaviour. It simply fixes the
> > > stall for kexec().
> > >
> > > The patch that introduced the stall:
> > > 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
> > > in .shutdown")
> >
> > That patch is problematic. I would go as far as saying that
> > it needs to be reverted.
>
> It fixes a real issue. We have not had any complaints until we tried
> to kexec in the platform.
> I wont recommend reverting it until we have an alternative implementation.
>
> kexec is far less common than suspend/reboot.
I've posted an alternative to ALSA list that reverts the problematic
patch and fixes the problem (the patch was originally addressing)
in a different way:
https://mailman.alsa-project.org/pipermail/alsa-devel/2022-December/209776.html
No changes outside sound/soc/ are needed with this approach.
Br, Kai
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
2022-12-01 13:22 ` Oliver Neukum
2022-12-01 13:34 ` Ricardo Ribalda
@ 2022-12-01 13:38 ` Takashi Iwai
1 sibling, 0 replies; 12+ messages in thread
From: Takashi Iwai @ 2022-12-01 13:38 UTC (permalink / raw)
To: Oliver Neukum
Cc: Ricardo Ribalda, Juergen Gross, Mark Brown, Chromeos Kdump,
Daniel Baluta, Christophe Leroy, Len Brown, Ard Biesheuvel,
Ranjani Sridharan, Rafael J. Wysocki, Boris Ostrovsky,
Nicholas Piggin, Michael Ellerman, Eric Biederman, Dave Hansen,
Jaroslav Kysela, Joel Fernandes, Liam Girdwood, Peter Ujfalusi,
Pavel Machek, Pierre-Louis Bossart, Kai Vehmanen, Steven Rostedt,
K. Y. Srinivasan, Ingo Molnar, Bjorn Helgaas, Dexuan Cui,
Takashi Iwai, H. Peter Anvin, Bard Liao, Haiyang Zhang, Wei Liu,
Thomas Gleixner, Borislav Petkov, x86, kexec, alsa-devel, stable,
sound-open-firmware, linuxppc-dev, linux-hyperv, linux-pci,
linux-pm, linux-kernel, linux-efi, xen-devel
On Thu, 01 Dec 2022 14:22:12 +0100,
Oliver Neukum wrote:
>
> On 01.12.22 14:03, Ricardo Ribalda wrote:
>
> Hi,
>
> > This patchset does not modify this behaviour. It simply fixes the
> > stall for kexec().
> >
> > The patch that introduced the stall:
> > 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
> > in .shutdown")
>
> That patch is problematic. I would go as far as saying that
> it needs to be reverted.
... or fixed.
> > was sent as a generalised version of:
> > https://github.com/thesofproject/linux/pull/3388
> >
> > AFAIK, we would need a similar patch for every single board.... which
> > I am not sure it is doable in a reasonable timeframe.
> >
> > On the meantime this seems like a decent compromises. Yes, a
> > miss-behaving userspace can still stall during suspend, but that was
> > not introduced in this patch.
>
> Well, I mean if you know what wrong then I'd say at least return to
> a sanely broken state.
>
> The whole approach is wrong. You need to be able to deal with user
> space talking to removed devices by returning an error and keeping
> the resources association with the open file allocated until
> user space calls close()
As I already mentioned in another thread, if the user-space action has
to be cut off, we just need to call snd_card_disconnect() instead
without sync. A quick hack would be like below (totally untested and
might be wrong, though).
In anyway, Ricardo, please stop spinning too frequently; v8 in a few
days is way too much, and now the recipient list became unmanageable.
Let's give people some time to review and consider a better solution
at first.
thanks,
Takashi
-- 8< --
--- a/sound/soc/sof/core.c
+++ b/sound/soc/sof/core.c
@@ -475,7 +475,7 @@ EXPORT_SYMBOL(snd_sof_device_remove);
int snd_sof_device_shutdown(struct device *dev)
{
struct snd_sof_dev *sdev = dev_get_drvdata(dev);
- struct snd_sof_pdata *pdata = sdev->pdata;
+ struct snd_soc_component *component;
if (IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE))
cancel_work_sync(&sdev->probe_work);
@@ -484,9 +484,9 @@ int snd_sof_device_shutdown(struct device *dev)
* make sure clients and machine driver(s) are unregistered to force
* all userspace devices to be closed prior to the DSP shutdown sequence
*/
- sof_unregister_clients(sdev);
-
- snd_sof_machine_unregister(sdev, pdata);
+ component = snd_soc_lookup_component(sdev->dev, NULL);
+ if (component && component->card && component->card->snd_card)
+ snd_card_disconnect(component->card->snd_card);
if (sdev->fw_state == SOF_FW_BOOT_COMPLETE)
return snd_sof_shutdown(sdev);
^ permalink raw reply [flat|nested] 12+ messages in thread