lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87frt82gj7.wl-tiwai@suse.de>
Date: Thu, 20 Jun 2024 09:57:00 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Shengjiu Wang <shengjiu.wang@....com>
Cc: lars@...afoo.de,
	perex@...ex.cz,
	tiwai@...e.com,
	broonie@...nel.org,
	linux-sound@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	alsa-devel@...a-project.org,
	shengjiu.wang@...il.com
Subject: Re: [RESEND PATCH] ALSA: dmaengine_pcm: terminate dmaengine before synchronize

On Thu, 20 Jun 2024 04:40:18 +0200,
Shengjiu Wang wrote:
> 
> When dmaengine supports pause function, in suspend state,
> dmaengine_pause() is called instead of dmaengine_terminate_async(),
> 
> In end of playback stream, the runtime->state will go to
> SNDRV_PCM_STATE_DRAINING, if system suspend & resume happen
> at this time, application will not resume playback stream, the
> stream will be closed directly, the dmaengine_terminate_async()
> will not be called before the dmaengine_synchronize(), which
> violates the call sequence for dmaengine_synchronize().

Hmm, I can't follow this state change.
Do you mean that:
- snd_pcm_drain() is performed for a playback stream
- while draining operation, the system goes to suspend
- the system resumes (but the application doesn't call resume yet)
- The stream is closed (without calling resume)
??

If so, it's rather an inconsistent PCM state in the core side, and can
be fixed by a simple call like below:

-- 8< --
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -2700,6 +2700,7 @@ void snd_pcm_release_substream(struct snd_pcm_substream *substream)
 	if (substream->ref_count > 0)
 		return;
 
+	snd_pcm_resume(substream);
 	snd_pcm_drop(substream);
 	if (substream->hw_opened) {
 		if (substream->runtime->state != SNDRV_PCM_STATE_OPEN)
-- 8< --

This will be no-op for the PCM device without SNDRV_PCM_INFO_RESUME.

But, this may need more rework, too; admittedly it imposes the
unnecessary resume of the stream although it shall be stopped and
closed immediately after that.  We may have some optimization in
addition.


thanks,

Takashi

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ