linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Peter Ujfalusi <peter.ujfalusi@linux.intel.com>,
	Takashi Iwai <tiwai@suse.com>,
	stable@vger.kernel.org, Mark Brown <broonie@kernel.org>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Ricardo Ribalda <ribalda@chromium.org>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	linux-kernel@vger.kernel.org,
	sound-open-firmware@alsa-project.org
Subject: Re: [PATCH v4] ALSA: core: Fix deadlock when shutdown a frozen userspace
Date: Tue, 29 Nov 2022 08:52:14 +0100	[thread overview]
Message-ID: <87edtmqjtd.wl-tiwai@suse.de> (raw)
In-Reply-To: <16ddcbb9-8afa-ff18-05f9-2e9e01baf3ea@linux.intel.com>

On Mon, 28 Nov 2022 18:26:03 +0100,
Pierre-Louis Bossart wrote:
> 
> 
> 
> On 11/28/22 11:04, Takashi Iwai wrote:
> > On Mon, 28 Nov 2022 17:49:20 +0100,
> > Pierre-Louis Bossart wrote:
> >>
> >>
> >>
> >> On 11/28/22 07:42, Ricardo Ribalda wrote:
> >>> During kexec(), the userspace is frozen. Therefore we cannot wait for it
> >>> to complete.
> >>>
> >>> Avoid running snd_sof_machine_unregister during shutdown.
> >>>
> >>> 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>
> >>> ---
> >>> To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> >>> To: Liam Girdwood <lgirdwood@gmail.com>
> >>> To: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
> >>> To: Bard Liao <yung-chuan.liao@linux.intel.com>
> >>> To: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
> >>> To: Kai Vehmanen <kai.vehmanen@linux.intel.com>
> >>> To: Daniel Baluta <daniel.baluta@nxp.com>
> >>> To: Mark Brown <broonie@kernel.org>
> >>> To: Jaroslav Kysela <perex@perex.cz>
> >>> To: Takashi Iwai <tiwai@suse.com>
> >>> Cc: sound-open-firmware@alsa-project.org
> >>> Cc: alsa-devel@alsa-project.org
> >>> Cc: linux-kernel@vger.kernel.org
> >>> ---
> >>> Changes in v4:
> >>> - Do not call snd_sof_machine_unregister from shutdown.
> >>> - Link to v3: https://lore.kernel.org/r/20221127-snd-freeze-v3-0-a2eda731ca14@chromium.org
> >>>
> >>> Changes in v3:
> >>> - Wrap pm_freezing in a function
> >>> - Link to v2: https://lore.kernel.org/r/20221127-snd-freeze-v2-0-d8a425ea9663@chromium.org
> >>>
> >>> Changes in v2:
> >>> - Only use pm_freezing if CONFIG_FREEZER 
> >>> - Link to v1: https://lore.kernel.org/r/20221127-snd-freeze-v1-0-57461a366ec2@chromium.org
> >>> ---
> >>>  sound/soc/sof/core.c | 7 ++-----
> >>>  1 file changed, 2 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c
> >>> index 3e6141d03770..9616ba607ded 100644
> >>> --- a/sound/soc/sof/core.c
> >>> +++ b/sound/soc/sof/core.c
> >>> @@ -475,19 +475,16 @@ 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;
> >>>  
> >>>  	if (IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE))
> >>>  		cancel_work_sync(&sdev->probe_work);
> >>>  
> >>>  	/*
> >>> -	 * make sure clients and machine driver(s) are unregistered to force
> >>> -	 * all userspace devices to be closed prior to the DSP shutdown sequence
> >>> +	 * make sure clients are unregistered prior to the DSP shutdown
> >>> +	 * sequence.
> >>>  	 */
> >>>  	sof_unregister_clients(sdev);
> >>>  
> >>> -	snd_sof_machine_unregister(sdev, pdata);
> >>> -
> >>
> >> The comment clearly says that we do want all userspace devices to be
> >> closed. This was added in 83bfc7e793b5 ("ASoC: SOF: core: unregister
> >> clients and machine drivers in .shutdown") precisely to avoid a platform
> >> hang if the devices are used after the shutdown completes.
> > 
> > The problem is that it wants the *close* of the user-space programs
> > unnecessarily.  Basically the shutdown can be seen as a sort of device
> > hot unplug; i.e. the disconnection of the device files and the cleanup
> > of device state are the main task.  The difference is that the hot
> > unplug (unbind) usually follows the sync for the all processes being
> > closed (so that you can release all resources gracefully), while this
> > step is skipped for the shutdown (no need for resource-free).
> 
> Sorry Takashi, I don't have enough background to follow your explanations.
> 
> As Kai mentioned it, this step helped with a S5 issue earlier in 2022.
> Removing this will mechanically bring the issue back and break other
> Chromebooks.

Yeah I don't mean that this fix is right, either.  But the earlier fix
has apparently a problem and needs another fix.

Though, it's not clear why the full unregister of clients is needed at
the first place; judging only from the patch description of commit
83bfc7e793b5, what we want is only to shut up the further user space
action?  If so, just call snd_card_disconnect() would suffice?


Takashi

  reply	other threads:[~2022-11-29  7:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 13:42 [PATCH v4] ALSA: core: Fix deadlock when shutdown a frozen userspace Ricardo Ribalda
2022-11-28 13:47 ` Takashi Iwai
2022-11-28 16:49 ` Pierre-Louis Bossart
2022-11-28 17:04   ` Takashi Iwai
2022-11-28 17:26     ` Pierre-Louis Bossart
2022-11-29  7:52       ` Takashi Iwai [this message]
2022-11-29 12:11         ` Kai Vehmanen
2022-11-30 15:49           ` Ricardo Ribalda

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=87edtmqjtd.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=daniel.baluta@nxp.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=ribalda@chromium.org \
    --cc=sound-open-firmware@alsa-project.org \
    --cc=stable@vger.kernel.org \
    --cc=tiwai@suse.com \
    --cc=yung-chuan.liao@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).