This is a series I worked on with Baolin in 2017 and 2018, but we
never quite managed to finish up the last pieces. During the
ALSA developer meetup at ELC-E 2018 in Edinburgh, a decision was
made to go with this approach for keeping best compatibility
with existing source code, and then I failed to follow up by
resending the patches.
Now I have patches for all remaining time_t uses in the kernel,
so it's absolutely time to revisit them. I have done more
review of the patches myself and found a couple of minor issues
that I have fixed up, otherwise the series is still the same as
before.
Conceptually, the idea of these patches is:
- 64-bit applications should see no changes at all, neither
compile-time nor run-time.
- 32-bit code compiled with a 64-bit time_t currently
does not work with ALSA, and requires kernel changes and/or
sound/asound.h changes
- Most 32-bit code using these interfaces will work correctly
on a modified kernel, with or without the uapi header changes.
- 32-bit code using SNDRV_TIMER_IOCTL_TREAD requires the
updated header file for 64-bit time_t support
- 32-bit i386 user space with 64-bit time_t is broken for
SNDRV_PCM_IOCTL_STATUS, SNDRV_RAWMIDI_IOCTL_STATUS and
SNDRV_PCM_IOCTL_SYNC_PTR because of i386 alignment. This is also
addressed by the updated uapi header.
- PCM mmap is currently supported on native x86 kernels
(both 32-bit and 64-bit) but not for compat mode. This series breaks
the 32-bit native mmap support for 32-bit time_t, but instead allows
it for 64-bit time_t on both native and compat kernels. This seems to
be the best trade-off, as mmap support is optional already, and most
32-bit code runs in compat mode anyway.
- I've tried to avoid breaking compilation of 32-bit code
as much as possible. Anything that does break however is likely code
that is already broken on 64-bit time_t and needs source changes to
fix them.
I hope I addressed all review comments by now, so please pull this
for linux-5.6.
A git branch with the same contents is available for testing at [1].
Arnd
[1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git y2038-alsa-v7
[2] https://lore.kernel.org/lkml/CAK8P3a2Os66+iwQYf97qh05W2JP8rmWao8zmKoHiXqVHv…
Changes since v6: (Arnd):
- Add a patch to update the API versions
- Hide a timespec reference in #ifndef __KERNEL__ to remove the
last reference to time_t
- Use a more readable way to do padding and describe it in the
changelog
- Rebase to linux-5.5-rc1, changing include/sound/soc-component.h
and sound/drivers/aloop.c as needed.
Changes since v5 (Arnd):
- Rebased to linux-5.4-rc4
- Updated to completely remove timespec and time_t references from alsa
- found and fixed a few bugs
Changes since v4 (Baolin):
- Add patch 5 to change trigger_tstamp member of struct snd_pcm_runtime.
- Add patch 8 to change internal timespec.
- Add more explanation in commit message.
- Use ktime_get_real_ts64() in patch 6.
- Split common code out into a separate function in patch 6.
- Fix tu->tread bug in patch 6 and remove #if __BITS_PER_LONG == 64 macro.
Changes since v3:
- Move struct snd_pcm_status32 to pcm.h file.
- Modify comments and commit message.
- Add new patch2 ~ patch6.
Changes since v2:
- Renamed all structures to make clear.
- Remove CONFIG_X86_X32 macro and introduced new compat_snd_pcm_status64_x86_32.
Changes since v1:
- Add one macro for struct snd_pcm_status_32 which only active in 32bits kernel.
- Convert pcm_compat.c to use struct snd_pcm_status_64.
- Convert pcm_native.c to use struct snd_pcm_status_64.
---
Arnd Bergmann (3):
ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.c
ALSA: add new 32-bit layout for snd_pcm_mmap_status/control
ALSA: bump uapi version numbers
Baolin Wang (6):
ALSA: Replace timespec with timespec64
ALSA: Avoid using timespec for struct snd_timer_status
ALSA: Avoid using timespec for struct snd_ctl_elem_value
ALSA: Avoid using timespec for struct snd_pcm_status
ALSA: Avoid using timespec for struct snd_rawmidi_status
ALSA: Avoid using timespec for struct snd_timer_tread
include/sound/pcm.h | 74 ++++++--
include/sound/soc-component.h | 4 +-
include/sound/timer.h | 4 +-
include/uapi/sound/asound.h | 145 +++++++++++++--
sound/core/pcm.c | 12 +-
sound/core/pcm_compat.c | 282 ++++++++----------------------
sound/core/pcm_lib.c | 38 ++--
sound/core/pcm_native.c | 226 +++++++++++++++++++++---
sound/core/rawmidi.c | 132 +++++++++++---
sound/core/rawmidi_compat.c | 87 +++------
sound/core/timer.c | 229 ++++++++++++++++++------
sound/core/timer_compat.c | 62 +------
sound/drivers/aloop.c | 2 +-
sound/pci/hda/hda_controller.c | 10 +-
sound/soc/intel/skylake/skl-pcm.c | 4 +-
15 files changed, 817 insertions(+), 494 deletions(-)
--
2.20.0
On Mon, Aug 17, 2020 at 03:00:24PM +0000, Roosen Henri wrote:
> On Mon, 2020-08-17 at 16:35 +0200, gregkh(a)linuxfoundation.org wrote:
> > On Mon, Aug 17, 2020 at 02:15:16PM +0000, Roosen Henri wrote:
> > > On Tue, 2020-06-09 at 16:18 +0200, Arnd Bergmann wrote:
> > > > On Tue, Jun 9, 2020 at 2:36 PM Roosen Henri <
> > > > Henri.Roosen(a)ginzinger.com> wrote:
> > > > > Hi Arnd,
> > > > >
> > > > > I hope you are well and could answer me a quick question.
> > > > >
> > > > > I've read on the kernel mailing-list that initially there was
> > > > > an
> > > > > intention to backport the final y2038 patches to v5.4. We're
> > > > > currently targeting to use the v5.4 LTS kernel for a project
> > > > > which
> > > > > should be y2038 compliant.
> > > > >
> > > > > I couldn't find all of the y2038-endgame patches in the current
> > > > > v5.4-stable branch. Are there any patches still required to be
> > > > > backported in order for v5.4 to be y2038 compliant, or can the
> > > > > remaining patches be ignored (because of only cleanup?)? Else,
> > > > > is
> > > > > there still an intention to get the v5.4 LTS kernel y2038
> > > > > compliant?
> > > >
> > > > I don't think there are currently any plans to merge my y2038-
> > > > endgame
> > > > branch
> > > > into the official linux-5.4 lts kernel, but you should be able to
> > > > just pull from
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=…
> > > >
> > > > and get the same results. If you see any problems with that,
> > > > please
> > > > report
> > > > that to me with Cc to the mailing list and perhaps gregkh, so I
> > > > can
> > > > see if
> > > > I can resolve it by rebasing my patches, or if he would like to
> > > > merge
> > > > the
> > > > patches.
> > >
> > > Pulling the y2038-endgame branch does lead to some conflicts, which
> > > are
> > > currently still kinda staightforward to solve.
> > >
> > > However I'd be very interested in getting this branch merged to
> > > v5.4,
> > > so we don't run into more difficult merge conflicts the coming
> > > years
> > > where the v5.4-LTS still gets stable updates (Dec, 2025) and
> > > possibly
> > > to get any related fixes from upstream.
> > >
> > > @Greg: any chance to get the y2038-endgame merged into v5.4.y?
> >
> > I have no idea what this really means, and what it entails, but odds
> > are, no :)
>
> I fully understand, thanks for your statement on this.
>
> >
> > Why not just use a newer kernel? Why are you stuck using a 5.4
> > kernel
> > for a device that has to live in 2038? That feels very foolish to
> > me...
>
> Oh I agree on that :) It's just that these are currently customer
> requirements.
Are you sure that customers really understand what they want?
Usually they want a well-supported, stable, system. Why do they care
about a specific kernel version? That feels odd.
Good luck!
greg k-h
On Mon, Aug 17, 2020 at 02:15:16PM +0000, Roosen Henri wrote:
> On Tue, 2020-06-09 at 16:18 +0200, Arnd Bergmann wrote:
> > On Tue, Jun 9, 2020 at 2:36 PM Roosen Henri <
> > Henri.Roosen(a)ginzinger.com> wrote:
> > > Hi Arnd,
> > >
> > > I hope you are well and could answer me a quick question.
> > >
> > > I've read on the kernel mailing-list that initially there was an
> > > intention to backport the final y2038 patches to v5.4. We're
> > > currently targeting to use the v5.4 LTS kernel for a project which
> > > should be y2038 compliant.
> > >
> > > I couldn't find all of the y2038-endgame patches in the current
> > > v5.4-stable branch. Are there any patches still required to be
> > > backported in order for v5.4 to be y2038 compliant, or can the
> > > remaining patches be ignored (because of only cleanup?)? Else, is
> > > there still an intention to get the v5.4 LTS kernel y2038
> > > compliant?
> >
> > I don't think there are currently any plans to merge my y2038-endgame
> > branch
> > into the official linux-5.4 lts kernel, but you should be able to
> > just pull from
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=…
> >
> > and get the same results. If you see any problems with that, please
> > report
> > that to me with Cc to the mailing list and perhaps gregkh, so I can
> > see if
> > I can resolve it by rebasing my patches, or if he would like to merge
> > the
> > patches.
>
> Pulling the y2038-endgame branch does lead to some conflicts, which are
> currently still kinda staightforward to solve.
>
> However I'd be very interested in getting this branch merged to v5.4,
> so we don't run into more difficult merge conflicts the coming years
> where the v5.4-LTS still gets stable updates (Dec, 2025) and possibly
> to get any related fixes from upstream.
>
> @Greg: any chance to get the y2038-endgame merged into v5.4.y?
I have no idea what this really means, and what it entails, but odds
are, no :)
Why not just use a newer kernel? Why are you stuck using a 5.4 kernel
for a device that has to live in 2038? That feels very foolish to me...
thanks,
greg k-h
