Message ID | 20221127-snd-freeze-v4-0-51ca64b7f2ab@chromium.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp5677362wrr; Mon, 28 Nov 2022 05:46:23 -0800 (PST) X-Google-Smtp-Source: AA0mqf4U/AvvuJEdg2RGbkdVM+diveiScKgc9UQK/nb4nDhnbuqGMt1x/L+OsP0uxW3LBKDQPUfK X-Received: by 2002:a05:6402:360a:b0:469:f59f:352e with SMTP id el10-20020a056402360a00b00469f59f352emr27529553edb.241.1669643183202; Mon, 28 Nov 2022 05:46:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669643183; cv=none; d=google.com; s=arc-20160816; b=T6qTJsyPFyAyLp4/NGq5358MU7KEhlt0CfL4lszmb9uP12i50DBWzpEqIp+6s6DfXr AR5BpO8k6/g6AaMFiTAUzmMcmmIsIT8lLGwPUkl5N+CyWMyKwIta6kbEnBA2lREyLCU+ jryUN7tBDrDn52vsZXkG1EODqGQ9YbfalUINfHUX0PRjy5+FX+PYru4O2NzQp7gLPuR1 V6RtA2gzDa9YHQBAUTdtEysqCNhfZd9Og3g+5Bpl5Z/Ci0TrOJPbjStzVCFZQl63q1h1 rZf2/L6xnJGgbWUvzCdMHSq29N+2R++7n0yW1yNVbszQq1yQc+z+1YTFq3KL1/XPhe1i HBAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=8xdIjoOikGdAZKov94FlnwSjqEqsO1SC5byhX9Q9RLU=; b=cUhqH2SHp8Hb1e7Jbw+0QhXpKP1l5S02qvD2OTdMIgFKi4EgCAmORKh0hRYB78pDS3 m1K2qQQB6LWGFfWgJXctfFH+LqWDD4nbHKclGNCzvR417qF6GexIPeF72QWaIBPqTnzx wA8Kpb+PYu6+xScflcpMd4rn0S39VJdJtQcvVqL/WBeTOOBmOsZV/QV0N9WA+kFVhn0e VSt7VHu4GYV2skP92ebDKcuLUIkMsSBVVdXBs8zRtwxv6fm1663VBMOFz43XOBH6b1oC BVTiCGRfg1iauIE+9A/P56fLRjTFomSo1C5S+SCLYkFF9TL1i17y2hAFPKHmhO/ZRDNa /ygQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jEvKo4Xz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id fj27-20020a0564022b9b00b0046a7c877f58si8411100edb.335.2022.11.28.05.45.59; Mon, 28 Nov 2022 05:46:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jEvKo4Xz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231994AbiK1NnY (ORCPT <rfc822;gah0developer@gmail.com> + 99 others); Mon, 28 Nov 2022 08:43:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231974AbiK1NnB (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 28 Nov 2022 08:43:01 -0500 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 38E633AC for <linux-kernel@vger.kernel.org>; Mon, 28 Nov 2022 05:42:55 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id b2so9586054eja.7 for <linux-kernel@vger.kernel.org>; Mon, 28 Nov 2022 05:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:from:to:cc:subject:date:message-id:reply-to; bh=8xdIjoOikGdAZKov94FlnwSjqEqsO1SC5byhX9Q9RLU=; b=jEvKo4Xz7BCEk5NFMOWgRBT/TrETg2qR5X6hoc/aB/wXvdRIsbpe2NAzulkGQxZrHu RLxjxQBfTIAxEHmK/FBOhhMItJbRKUaqD2gCLiH4qrTnyxOUpRQAAadH/5fX/rfkFySY ZCD3BJnuyzNHoFJOjRR5/RFZmhAM7rd9nHyvg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:message-id:content-transfer-encoding:mime-version:subject :date:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8xdIjoOikGdAZKov94FlnwSjqEqsO1SC5byhX9Q9RLU=; b=67YDCYSKtvR3i7fhuwuwEy7iulUJKvZn2O+9nH9xtpsqd/ti3SDjBAEfhXRZwj40Np db8a6YhyqsIPb7a0rlR3xIxksB1lAWpiyipfCRZod4puDxh0QmjxFJfm7OCtnS9JPu5u 2zkWnYyzNEvwPocZ6qOtYsosepPzsLgF+6VdYX5xouSB6zc//GYx9EyfqVAyisNr+HSb C4u0PLVjzWMvYsrdffIe9zZCeYxm1tpwb0y8S+JcO9A6sDHNnEdGnW0V1Mz4WzpsgIXQ hMUC7yP/vLP82whzBdixByoSTfiCli92EPZQn/A+itGMY1h2YyeQoncjUdP5qNHmd6jy G3xA== X-Gm-Message-State: ANoB5pmTuq0ycSJhXem08qW2E+mfP8wcsyn9dRbpHB26h67k9Od5ASfZ 2eo7SCApxXOAzqIftFvFNA8Syg== X-Received: by 2002:a17:906:692:b0:7ad:49b8:1687 with SMTP id u18-20020a170906069200b007ad49b81687mr33385064ejb.407.1669642973563; Mon, 28 Nov 2022 05:42:53 -0800 (PST) Received: from alco.roam.corp.google.com (80.71.134.83.ipv4.parknet.dk. [80.71.134.83]) by smtp.gmail.com with ESMTPSA id vt4-20020a170907a60400b0073d7b876621sm4959667ejc.205.2022.11.28.05.42.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Nov 2022 05:42:53 -0800 (PST) From: Ricardo Ribalda <ribalda@chromium.org> Date: Mon, 28 Nov 2022 14:42:49 +0100 Subject: [PATCH v4] ALSA: core: Fix deadlock when shutdown a frozen userspace MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20221127-snd-freeze-v4-0-51ca64b7f2ab@chromium.org> To: Kai Vehmanen <kai.vehmanen@linux.intel.com>, Jaroslav Kysela <perex@perex.cz>, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>, Peter Ujfalusi <peter.ujfalusi@linux.intel.com>, Mark Brown <broonie@kernel.org>, Daniel Baluta <daniel.baluta@nxp.com>, Bard Liao <yung-chuan.liao@linux.intel.com>, Takashi Iwai <tiwai@suse.com>, Ranjani Sridharan <ranjani.sridharan@linux.intel.com>, Liam Girdwood <lgirdwood@gmail.com> Cc: Ricardo Ribalda <ribalda@chromium.org>, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, stable@vger.kernel.org, sound-open-firmware@alsa-project.org X-Mailer: b4 0.11.0-dev-696ae X-Developer-Signature: v=1; a=openpgp-sha256; l=3529; i=ribalda@chromium.org; h=from:subject:message-id; bh=CuZgvNcaSIcLqEhNVxL+uczDhS4EM71Cxydwohy6ArE=; b=owEBbQKS/ZANAwAKAdE30T7POsSIAcsmYgBjhLraAkpShzLacNLIjWc+7CfukKCbU2FcaQSEkkOd E8G3s4KJAjMEAAEKAB0WIQREDzjr+/4oCDLSsx7RN9E+zzrEiAUCY4S62gAKCRDRN9E+zzrEiGH7EA CNcjEMcS8oZDbadEJ0IDQyhibQPQceQUEVYKPeBv62cDgSKswxDoYu7I21X8O3OW/ETvQDNB35/q+/ zePdiuhYJAeq1gaZ0ZIQp1gnjL9UXoYe06jde9gfB2aSfGhIhftVfaonKSf8Htyc/QMGq5D9oOZp4Q dYHsRJz4U/vgGfQH+jw6e9OTfOrMPK3eYsBGj5KoLFHloSVasKuWkhbUew0gkoUwQ/alk1/D2wnc3x +L7Hb+PaA81/r27oPmxZsAyS5j/b0a+MOZQHklYy057opBh2yFiBzxtHHVAaMkfWSDNkP1TlQb0G+k yGL+d1q6+Tr20HenI6fYnRlZqLSsemE71t/IDYLqaqBzw3rb5HSgOE4Rvoflp0rvehq7SbPg5a4nBV 0xqBwSM0EhLUmkO8uelk8FP36MCIEqMgb1f2WZk1tnKow0opnWYhYxVEI+S+glbxB0M6PnIThE8v+t srJTQmnIL6SyHOYuPyixoYX74/acbjKa/aNBVtpVhI/9vImy2CcNVSJvs+iUfBcueS/D9bQd77BUb8 rp84vTCAMUWPQRwbZPWXYf7XbUjWrBerTZKGq3rD6omJ6zuReFxmAHWhCtr0kk4SFFGCauSoGeN63s eaC7xewSghyIwwa1bFPaIqN0Hsd9ukkUo1nUInfZPdx3d5lQxv6NGnPBjCRg== X-Developer-Key: i=ribalda@chromium.org; a=openpgp; fpr=9EC3BB66E2FC129A6F90B39556A0D81F9F782DA9 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750730547255576410?= X-GMAIL-MSGID: =?utf-8?q?1750747770787860076?= |
Series |
[v4] ALSA: core: Fix deadlock when shutdown a frozen userspace
|
|
Commit Message
Ricardo Ribalda
Nov. 28, 2022, 1:42 p.m. UTC
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(-)
---
base-commit: 4312098baf37ee17a8350725e6e0d0e8590252d4
change-id: 20221127-snd-freeze-1ee143228326
Best regards,
Comments
On Mon, 28 Nov 2022 14:42:49 +0100, 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 The subject prefix should be adjusted -- now it's no longer about ALSA core but specific to ASoC SOF. thanks, Takashi
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. So you are not fixing 83bfc7e793b5, just re-adding a problem to fix another one...
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). Takashi
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.
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
Hi On Tue, 29 Nov 2022, Takashi Iwai wrote: > On Mon, 28 Nov 2022 18:26:03 +0100, Pierre-Louis Bossart wrote: > > 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? I think the snd_card_disconnect() is what we are looking after here, but it's just easiest to do via unregister in SOF as that will trigger will look up the platform device, unregister it, and it eventually the driver owning the card will do the disconnect. Possibility for sure to do a more direct implementation and not run the full unregister. On the other end of the solution spectrum, we had this alternative to let user-space stay connected and just have the DSP implementations handle any pending work in their respective shutdown handlers. I.e. we had "ASoC: SOF: Intel: pci-tgl: unblock S5 entry if DMA stop has failed" https://github.com/thesofproject/linux/pull/3388 This was eventually dropped (and never sent upstream) as 83bfc7e793b5 got the same result, and covered all SOF platforms with a single code path. Bringing this back is of course one option, but then this might suprise other platforms (which might have got used to user-space getting disconnected at shutdown via 83bfc7e793b5). Br, Kai
Hi I just sent a v6 that only avoids unregistering the clients during kexec... let me know if that works for you Thanks! On Tue, 29 Nov 2022 at 13:12, Kai Vehmanen <kai.vehmanen@linux.intel.com> wrote: > > Hi > > On Tue, 29 Nov 2022, Takashi Iwai wrote: > > > On Mon, 28 Nov 2022 18:26:03 +0100, Pierre-Louis Bossart wrote: > > > 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? > > I think the snd_card_disconnect() is what we are looking after here, but > it's just easiest to do via unregister in SOF as that will trigger will > look up the platform device, unregister it, and it eventually the driver > owning the card will do the disconnect. Possibility for sure to do a more > direct implementation and not run the full unregister. > > On the other end of the solution spectrum, we had this alternative to let > user-space stay connected and just have the DSP implementations handle > any pending work in their respective shutdown handlers. I.e. we had > "ASoC: SOF: Intel: pci-tgl: unblock S5 entry if DMA stop has failed" > https://github.com/thesofproject/linux/pull/3388 > > This was eventually dropped (and never sent upstream) as 83bfc7e793b5 got > the same result, and covered all SOF platforms with a single code path. > Bringing this back is of course one option, but then this might suprise > other platforms (which might have got used to user-space getting > disconnected at shutdown via 83bfc7e793b5). > > Br, Kai
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); - if (sdev->fw_state == SOF_FW_BOOT_COMPLETE) return snd_sof_shutdown(sdev);