Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp440392rwb; Tue, 29 Nov 2022 00:11:21 -0800 (PST) X-Google-Smtp-Source: AA0mqf6IRCZ1EsSMQfjNTQnJDCwP1l+839GRrkmCMAw8rdET+lH0QNur89Ac4QLYdtTuJoGPRSCC X-Received: by 2002:aa7:d5d4:0:b0:46a:96b3:57bc with SMTP id d20-20020aa7d5d4000000b0046a96b357bcmr21660315eds.231.1669709481582; Tue, 29 Nov 2022 00:11:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669709481; cv=none; d=google.com; s=arc-20160816; b=NxHL/ag5J08fcmTiS2NxynnuDZycg/pIauvWnZZM1FODTg0n0BMcHovxh/VfkOgXh/ 8c/3wJ4IVKSSin7dMjm4EYsi2z6VO92yVSQq3v1hC49gTz1XOXYPZ3QpKXFw0W1H1vjL /jRIUSELR4TnNetxAY7C5xQmxO8cNwIrLHPdl83Xtzr9nDSP2rjlSaJojE4QLThgCjXc JvY/tBwTIe3mTooqzyNoeHWOwmgzw4EBPppoOLo0E4uhS2jlUmxU12CtH/dYmbU1Di3o vdNwd9Wl8hBw9aDvMLSbV8M1CK8aO46cE4rw88ltKRdo+YpCOewMyZr73lSRkxXekZv/ w/TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :subject:cc:to:from:message-id:date:dkim-signature:dkim-signature; bh=UCtXcvqaOALnEXAnaeywfxvt3BaAGjAT6PCuZBjIu8U=; b=c8f332U3aLo1EQzyl+SnU5nfHaU9ZSpHwOFBZwvkW1y0FTKU1GCVKLQb1Vu1X6bEQi PyfmbvAQ6urvO49PVfkv62t73UidbYC6W4jaIJND/2VW8n6nASIyZ5gTn9pFWxeO80F3 H+hpCzQcSCg0LjkFucSbRAmAd+K8ChJbxRFCa0+kX6t/j50S5Ie53sTbGK2td7SBGCdX Gzc4pg8Q8cZZHrv4ej5HkE8FyroVztmwA5WwCRGNxiNioT7B1ML6wI3upDAq+bfkNHnq 7JFME8e0d2ibujCPBgLs28v57pzPeM6lJMlFan/9WI3zkvcNR8UCDqhmXYhrNbphQNBg kwnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=w2WuPzBe; dkim=neutral (no key) header.i=@suse.de; 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=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hc7-20020a170907168700b0078db719e54csi13847251ejc.98.2022.11.29.00.11.00; Tue, 29 Nov 2022 00:11:21 -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=@suse.de header.s=susede2_rsa header.b=w2WuPzBe; dkim=neutral (no key) header.i=@suse.de; 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=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229795AbiK2HwX (ORCPT + 84 others); Tue, 29 Nov 2022 02:52:23 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43656 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229777AbiK2HwR (ORCPT ); Tue, 29 Nov 2022 02:52:17 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8132C51C2E; Mon, 28 Nov 2022 23:52:16 -0800 (PST) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 383601FDE2; Tue, 29 Nov 2022 07:52:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1669708335; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UCtXcvqaOALnEXAnaeywfxvt3BaAGjAT6PCuZBjIu8U=; b=w2WuPzBeAs1MfNmadXyGfVU7XEo/xH1XPlDu5ki2ZRFXbijfTybWEQ6idq1JEd7ez3I5Wk vUg+i+5NrABlFQW/5l5WEREHF+IUO4iMjKjPfrkuMkydu1A0edIsnE5XrRV9pGgfR0M+er HNLl5xkMERfEjnlgQEN83wbbrJ1xCAU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1669708335; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=UCtXcvqaOALnEXAnaeywfxvt3BaAGjAT6PCuZBjIu8U=; b=jd4pQJztqijSHbDWUB9WprF7eznFZ0UG4K4ozQvp3E5JUKwj6c2aH8eCuaxNdAbG9E5mFA QzJpEDCBLMnTgWBg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E047413428; Tue, 29 Nov 2022 07:52:14 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id EJcFNi66hWPEcAAAMHmgww (envelope-from ); Tue, 29 Nov 2022 07:52:14 +0000 Date: Tue, 29 Nov 2022 08:52:14 +0100 Message-ID: <87edtmqjtd.wl-tiwai@suse.de> From: Takashi Iwai To: Pierre-Louis Bossart Cc: alsa-devel@alsa-project.org, Kai Vehmanen , Liam Girdwood , Peter Ujfalusi , Takashi Iwai , stable@vger.kernel.org, Mark Brown , Bard Liao , Ranjani Sridharan , Ricardo Ribalda , Daniel Baluta , linux-kernel@vger.kernel.org, sound-open-firmware@alsa-project.org Subject: Re: [PATCH v4] ALSA: core: Fix deadlock when shutdown a frozen userspace In-Reply-To: <16ddcbb9-8afa-ff18-05f9-2e9e01baf3ea@linux.intel.com> References: <20221127-snd-freeze-v4-0-51ca64b7f2ab@chromium.org> <5171929e-b750-d2f1-fec9-b34d76c18dcb@linux.intel.com> <87mt8bqaca.wl-tiwai@suse.de> <16ddcbb9-8afa-ff18-05f9-2e9e01baf3ea@linux.intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,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: X-Mailing-List: linux-kernel@vger.kernel.org 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] > >>> [ 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] > >>> [ 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 > >>> --- > >>> To: Pierre-Louis Bossart > >>> To: Liam Girdwood > >>> To: Peter Ujfalusi > >>> To: Bard Liao > >>> To: Ranjani Sridharan > >>> To: Kai Vehmanen > >>> To: Daniel Baluta > >>> To: Mark Brown > >>> To: Jaroslav Kysela > >>> To: Takashi Iwai > >>> 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