linux-kernel - [PATCH 4.9 043/138] ALSA: pcm: update tstamp only if audio

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Nov 2017 11:22:24 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     linux-kernel@...r.kernel.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable@...r.kernel.org,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Henrik Eriksson <henrik.eriksson@...s.com>,
        Takashi Iwai <tiwai@...e.de>
Subject: [PATCH 4.9 043/138] ALSA: pcm: update tstamp only if audio_tstamp changed

4.9-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Henrik Eriksson <henrik.eriksson@...s.com>

commit 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71 upstream.

commit 3179f6200188 ("ALSA: core: add .get_time_info") had a side effect
of changing the behaviour of the PCM runtime tstamp.  Prior to this
change tstamp was not updated by snd_pcm_update_hw_ptr0() unless the
hw_ptr had moved, after this change tstamp was always updated.

For an application using alsa-lib, doing snd_pcm_readi() followed by
snd_pcm_status() to estimate the age of the read samples by subtracting
status->avail * [sample rate] from status->tstamp this change degraded
the accuracy of the estimate on devices where the pcm hw does not
provide a granular hw_ptr, e.g., devices using
soc-generic-dmaengine-pcm.c and a dma-engine with residue_granularity
DMA_RESIDUE_GRANULARITY_DESCRIPTOR.  The accuracy of the estimate
depended on the latency between the PCM hw completing a period and the
driver called snd_pcm_period_elapsed() to notify ALSA core, typically
determined by interrupt handling latency.  After the change the accuracy
of the estimate depended on the latency between the PCM hw completing a
period and the application calling snd_pcm_status(), determined by the
scheduling of the application process.  The maximum error of the
estimate is one period length in both cases, but the error average and
variance is smaller when it depends on interrupt latency.

Instead of always updating tstamp, update it only if audio_tstamp
changed.

Fixes: 3179f6200188 ("ALSA: core: add .get_time_info")
Suggested-by: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
Signed-off-by: Henrik Eriksson <henrik.eriksson@...s.com>
Signed-off-by: Takashi Iwai <tiwai@...e.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

---
 sound/core/pcm_lib.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -264,8 +264,10 @@ static void update_audio_tstamp(struct s
 				runtime->rate);
 		*audio_tstamp = ns_to_timespec(audio_nsecs);
 	}
-	runtime->status->audio_tstamp = *audio_tstamp;
-	runtime->status->tstamp = *curr_tstamp;
+	if (!timespec_equal(&runtime->status->audio_tstamp, audio_tstamp)) {
+		runtime->status->audio_tstamp = *audio_tstamp;
+		runtime->status->tstamp = *curr_tstamp;
+	}

 	/*
 	 * re-take a driver timestamp to let apps detect if the reference tstamp