linux-kernel - Re: [PATCH v2 0/4] ALSA: compress_offload: Add 64-bit safe timestamp API

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]

Message-ID: <87wm8eg9ve.wl-tiwai@suse.de>
Date: Fri, 11 Jul 2025 15:00:53 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Joris Verhaegen <verhaegen@...gle.com>
Cc: Charles Keepax <ckeepax@...nsource.cirrus.com>,
	Vinod Koul <vkoul@...nel.org>,
	Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Richard Fitzgerald <rf@...nsource.cirrus.com>,
	David Rhodes <david.rhodes@...rus.com>,
	Cezary Rojewski <cezary.rojewski@...el.com>,
	Peter Ujfalusi <peter.ujfalusi@...ux.intel.com>,
	Bard Liao <yung-chuan.liao@...ux.intel.com>,
	Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
	Kai Vehmanen <kai.vehmanen@...ux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>,
	Srinivas Kandagatla <srini@...nel.org>,
	Daniel Baluta <daniel.baluta@....com>,
	Orson Zhai <orsonzhai@...il.com>,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Chunyan Zhang <zhang.lyra@...il.com>,
	Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	kernel-team@...roid.com,
	linux-sound@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	patches@...nsource.cirrus.com,
	linux-arm-msm@...r.kernel.org,
	sound-open-firmware@...a-project.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 0/4] ALSA: compress_offload: Add 64-bit safe timestamp API

On Fri, 11 Jul 2025 14:41:05 +0200,
Takashi Iwai wrote:
> 
> On Fri, 11 Jul 2025 13:56:47 +0200,
> Charles Keepax wrote:
> > 
> > On Fri, Jul 11, 2025 at 10:36:26AM +0100, Joris Verhaegen wrote:
> > > The current compress offload timestamping API relies on
> > > struct snd_compr_tstamp, whose cumulative counters like
> > > copied_total are defined as __u32. On long-running high-resolution
> > > audio streams, these 32-bit counters can overflow,
> > > causing incorrect availability calculations.
> > > 
> > > This patch series introduces a parallel, 64-bit safe API to solve
> > > this problem while maintaining perfect backward compatibility with the
> > > existing UAPI. A new pointer64 operation and corresponding ioctls
> > > are added to allow the kernel to track counters using u64 and expose
> > > these full-width values to user-space.
> > > 
> > > The series is structured as follows:
> > > 
> > > Patch 1: Introduces the new internal pointer64 op, refactors the
> > > core logic to use it, and defines the new UAPI structs.
> > > 
> > > Patch 2: Exposes the SNDRV_COMPRESS_TSTAMP64 ioctl.
> > > 
> > > Patch 3: Exposes the corresponding SNDRV_COMPRESS_AVAIL64 ioctl.
> > > 
> > > Patch 4: Implements the new .pointer64 operation in various ASoC
> > > drivers that support compress offload.
> > > 
> > > This series has been tested on a Pixel 9 device. All compress offload
> > > use cases, including long-running playback, were verified to work
> > > correctly with the new 64-bit API, and no regressions were observed
> > > when using the legacy API.
> > > 
> > > Thanks,
> > > Joris (George) Verhaegen
> > > 
> > > Signed-off-by: Joris Verhaegen <verhaegen@...gle.com>
> > > 
> > > ---
> > 
> > Would it not be slightly simpler to just update all the in kernel
> > bits to use 64-bit and then only convert to 32-bit for the
> > existing 32-bit IOCTLs? Why do we need 32-bit callbacks into the
> > drivers for example?
> 
> Right, it's a usual pattern to have only the 64bit ops in the kernel
> driver side while providing the 32bit stuff converted in the core
> layer.  Having two different ops are rather confusing and
> superfluous after conversions.
> 
> If there are tons of users for this API, it'd be needed to convert
> gradually, and eventually drop the 32bit ops at the end.  But in this
> case, there doesn't seem so many relevant drivers, hence the
> conversion can be done in a shot as done in your patch 4.

Also, don't forget to increase the protocol version if you change the
ABI.


thanks,

Takashi