[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hpmsh9kdx.wl-tiwai@suse.de>
Date: Thu, 07 Oct 2021 12:52:58 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Michael Forney <mforney@...rney.org>
Cc: Arnd Bergmann <arnd@...db.de>, alsa-devel@...a-project.org,
Takashi Iwai <tiwai@...e.com>,
Baolin Wang <baolin.wang@...aro.org>, y2038@...ts.linaro.org,
linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>,
Baolin Wang <baolin.wang7@...il.com>
Subject: Re: [alsa-devel] [PATCH v7 8/9] ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
On Wed, 06 Oct 2021 19:49:17 +0200,
Michael Forney wrote:
>
> Arnd Bergmann <arnd@...db.de> wrote:
> > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __BIG_ENDIAN : defined(__BIG_ENDIAN)
> > +typedef char __pad_before_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +typedef char __pad_after_uframe[0];
> > +#endif
> > +
> > +#if defined(__BYTE_ORDER) ? __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
> > +typedef char __pad_before_uframe[0];
> > +typedef char __pad_after_uframe[sizeof(__u64) - sizeof(snd_pcm_uframes_t)];
> > +#endif
> > +
> > +struct __snd_pcm_mmap_status64 {
> > + __s32 state; /* RO: state - SNDRV_PCM_STATE_XXXX */
> > + __u32 pad1; /* Needed for 64 bit alignment */
> > + __pad_before_uframe __pad1;
> > + snd_pcm_uframes_t hw_ptr; /* RO: hw ptr (0...boundary-1) */
> > + __pad_after_uframe __pad2;
> > + struct __snd_timespec64 tstamp; /* Timestamp */
> > + __s32 suspended_state; /* RO: suspended stream state */
> > + __u32 pad3; /* Needed for 64 bit alignment */
> > + struct __snd_timespec64 audio_tstamp; /* sample counter or wall clock */
> > +};
> > +
> > +struct __snd_pcm_mmap_control64 {
> > + __pad_before_uframe __pad1;
> > + snd_pcm_uframes_t appl_ptr; /* RW: appl ptr (0...boundary-1) */
> > + __pad_before_uframe __pad2;
>
> I was looking through this header and happened to notice that this
> padding is wrong. I believe it should be __pad_after_uframe here.
>
> I'm not sure of the implications of this typo, but I suspect it
> breaks something on 32-bit systems with 64-bit time (regardless of
> the endianness, since it changes the offset of avail_min).
Right, that's the expected breakage. It seems that the 64bit time on
32bit arch is still rare, so we haven't heard a regression by that, so
far...
In anyway, care to send a formal fix patch?
Thanks for catching this!
Takashi
Powered by blists - more mailing lists