From: Takashi Iwai <tiwai@suse.de>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Takashi Iwai <tiwai@suse.com>, Len Brown <len.brown@intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
Pavel Machek <pavel@ucw.cz>,
"Rafael J. Wysocki" <rafael@kernel.org>,
alsa-devel@alsa-project.org,
"Joel Fernandes (Google)" <joel@joelfernandes.org>,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH v3 0/2] ALSA: core: Fix deadlock when shutdown a frozen userspace
Date: Mon, 28 Nov 2022 10:53:55 +0100 [thread overview]
Message-ID: <87tu2jz9os.wl-tiwai@suse.de> (raw)
In-Reply-To: <CANiDSCtSAM3seszVWfjJPaYFO3v223P-tYEtdpW4+pQQ3bcf0g@mail.gmail.com>
On Mon, 28 Nov 2022 10:26:36 +0100,
Ricardo Ribalda wrote:
>
> Hi Takashi
>
> Thanks for your prompt reply
>
> On Mon, 28 Nov 2022 at 10:24, Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Mon, 28 Nov 2022 10:10:12 +0100,
> > Ricardo Ribalda wrote:
> > >
> > > Since 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers in .shutdown")
> > > we wait for userspace to close its fds.
> >
> > IMO, the fix above brought more problem. If you'd need to want to
> > avoid later accesses during shutdown, the driver should rather just
> > disconnect devices without waiting for the user-space completion.
> > And, for that, a simple call of snd_card_disconnect() should suffice.
> >
> > > But that will never occur with a frozen userspace (like during kexec()).
> > >
> > > Lets detect the frozen userpace and act accordingly.
> >
> > ... and skipping the user-space sync at snd_card_disconnect_sync() as
> > of this patch set is a dangerous move, I'm afraid. The user-space
> > gets frozen also at the normal suspend/resume, and it implies that the
> > sync will be lost even for the normal PM, too (although it must be a
> > very corner case).
> >
>
> And what about checking kexec_in_progress instead?
I still think that the call of snd_card_disconnect_sync() itself at
shutdown is somehow wrong. If this only comes from the SOF code path
above, we should address in that code path instead.
OTOH, you showed two code paths: one is
[ 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 another is
[ 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
The former is likely the SOF code path by the commit you mentioned
(but it's not 100% clear because you trimmed the stack trace), and
this should be reconsidered.
But, the latter seems to be independent from that. If that's the code
path where the unbind is triggered before kexec, your fix might not
work, either; it could be already at the wait_event*() when kexec
starts.
Maybe a simpler workaround would be to replace it with
wait_event_killable*() stuff. But whether we can discontinue the sync
there is still another thing to consider...
Takashi
>
> Thanks!
>
> >
> > thanks,
> >
> > Takashi
> >
> > >
> > > To: Jaroslav Kysela <perex@perex.cz>
> > > To: Takashi Iwai <tiwai@suse.com>
> > > To: "Rafael J. Wysocki" <rafael@kernel.org>
> > > To: Pavel Machek <pavel@ucw.cz>
> > > To: Len Brown <len.brown@intel.com>
> > > To: Kai Vehmanen <kai.vehmanen@linux.intel.com>
> > > To: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
> > > To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
> > > To: Mark Brown <broonie@kernel.org>
> > > Cc: alsa-devel@alsa-project.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Cc: "Joel Fernandes (Google)" <joel@joelfernandes.org>
> > > Cc: linux-pm@vger.kernel.org
> > > Signed-off-by: Ricardo Ribalda <ribalda@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
> > >
> > > ---
> > > Ricardo Ribalda (2):
> > > freezer: Add processes_frozen()
> > > ALSA: core: Fix deadlock when shutdown a frozen userspace
> > >
> > > include/linux/freezer.h | 2 ++
> > > kernel/freezer.c | 11 +++++++++++
> > > sound/core/init.c | 13 +++++++++++++
> > > 3 files changed, 26 insertions(+)
> > > ---
> > > base-commit: 4312098baf37ee17a8350725e6e0d0e8590252d4
> > > change-id: 20221127-snd-freeze-1ee143228326
> > >
> > > Best regards,
> > > --
> > > Ricardo Ribalda <ribalda@chromium.org>
> > >
>
>
>
> --
> Ricardo Ribalda
>
next prev parent reply other threads:[~2022-11-28 9:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 9:10 [PATCH v3 0/2] ALSA: core: Fix deadlock when shutdown a frozen userspace Ricardo Ribalda
2022-11-28 9:10 ` [PATCH v3 1/2] freezer: Add processes_frozen() Ricardo Ribalda
2022-11-28 9:10 ` [PATCH v3 2/2] ALSA: core: Fix deadlock when shutdown a frozen userspace Ricardo Ribalda
2022-11-28 9:24 ` [PATCH v3 0/2] " Takashi Iwai
2022-11-28 9:26 ` Ricardo Ribalda
2022-11-28 9:53 ` Takashi Iwai [this message]
2022-11-28 13:34 ` Ricardo Ribalda
2022-11-28 9:26 ` Oliver Neukum
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=87tu2jz9os.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=joel@joelfernandes.org \
--cc=kai.vehmanen@linux.intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=rafael@kernel.org \
--cc=ranjani.sridharan@linux.intel.com \
--cc=ribalda@chromium.org \
--cc=tiwai@suse.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