The ioctl definitions for XFS_IOC_SWAPEXT, XFS_IOC_FSBULKSTAT and
XFS_IOC_FSBULKSTAT_SINGLE are part of libxfs and based on time_t.
The definition for time_t differs between current kernels and coming
32-bit libc variants that define it as 64-bit. For most ioctls, that
means the kernel has to be
The ioctl definitions for XFS_IOC_SWAPEXT, XFS_IOC_FSBULKSTAT and
XFS_IOC_FSBULKSTAT_SINGLE are part of libxfs and based on time_t.
The definition for time_t differs between current kernels and coming
32-bit libc variants that define it as 64-bit. For most ioctls, that
means the kernel has to be
This is part of a longer set of changes to clean up the last remaining
bits for the y2038 conversion. In XFS, three distinct problems need to
be addressed:
1. The use of time_t in kernel sources -- I'm in the process
of removing all of them so we can remove the definition itself,
making it
The quota handling in xfs is based around an in-memory representation
of time_t, which overflows in year 2038 on 32-bit architectures, and an
on-disk representation of __be32, which overflows in year 2106 based
on interpreting the values as unsigned.
Extend both to allow for much longer times:
XFS is the only major file system that lacks timestamps beyond year 2038,
and is already being deployed in systems that may have to be supported
beyond that time.
Fortunately, the inode format still has a few reserved bits that can be
used to extend the current format. There are two bits in the
On Tue, 12 Nov 2019 21:04:10 +0100,
Arnd Bergmann wrote:
>
> On Tue, Nov 12, 2019 at 5:38 PM Takashi Iwai wrote:
> > On Tue, 12 Nov 2019 16:16:39 +0100, Arnd Bergmann wrote:
> > > +#ifndef __KERNEL__
> > > struct snd_rawmidi_status {
> > > int stream;
> > > + unsigned char
On Tue, Nov 12, 2019 at 4:42 PM Takashi Iwai wrote:
> > @@ -761,6 +761,7 @@ struct snd_timer_params {
> > unsigned char reserved[60]; /* reserved */
> > };
> >
> > +#ifndef __KERNEL__
> > struct snd_timer_status {
> > struct timespec tstamp; /* Timestamp - last update
On Tue, Nov 12, 2019 at 5:38 PM Takashi Iwai wrote:
> On Tue, 12 Nov 2019 16:16:39 +0100, Arnd Bergmann wrote:
> > +#ifndef __KERNEL__
> > struct snd_rawmidi_status {
> > int stream;
> > + unsigned char pad1[sizeof(time_t) - sizeof(int)];
> > struct timespec tstamp; /*
On Tue, 12 Nov 2019 16:16:34 +0100,
Arnd Bergmann wrote:
>
> 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
On Tue, Nov 12, 2019 at 01:09:09PM +0100, Arnd Bergmann wrote:
> XFS is the only major file system that lacks timestamps beyond year 2038,
> and is already being deployed in systems that may have to be supported
> beyond that time.
>
> Fortunately, the inode format still has a few reserved bits
On Tue, 12 Nov 2019 21:08:17 +0100,
Arnd Bergmann wrote:
>
> On Tue, Nov 12, 2019 at 4:42 PM Takashi Iwai wrote:
>
> > > @@ -761,6 +761,7 @@ struct snd_timer_params {
> > > unsigned char reserved[60]; /* reserved */
> > > };
> > >
> > > +#ifndef __KERNEL__
> > > struct
On Fri, Nov 08, 2019 at 10:12:10PM +0100, Arnd Bergmann wrote:
> There are two 'struct timeval' fields in 'struct rusage'.
>
> Unfortunately the definition of timeval is now ambiguous when used in
> user space with a libc that has a 64-bit time_t, and this also changes
> the 'rusage' definition
On Fri, Nov 08, 2019 at 10:32:52PM +0100, Arnd Bergmann wrote:
> The timespec structure and associated interfaces are deprecated and will
> be removed in the future because of the y2038 overflow.
>
> The use of ktime_to_timespec() in timeout_to_jiffies() does not
> suffer from that overflow, but
On Tue, Nov 12, 2019 at 4:16 PM Christoph Hellwig wrote:
>
> Amir just send another patch dealing with the time stamps. I'd suggest
> you chime into the discussion in that thread.
That's right I just posted the ext4 style extend to 34bits yesterday [1],
but I like your version so much better,
From: Baolin Wang
Since timespec is not year 2038 safe on 32bit system, and we need to
convert all timespec variables to timespec64 type for sound subsystem.
This patch is used to do preparation for following patches, that will
convert all structures defined in uapi/sound/asound.h to use 64-bit
The snd_pcm_mmap_status and snd_pcm_mmap_control interfaces are one of the
trickiest areas to get right when moving to 64-bit time_t in user space.
The snd_pcm_mmap_status structure layout is incompatible with user space
that uses a 64-bit time_t, so we need a new layout for it. Since the
From: Baolin Wang
The struct snd_pcm_status will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Userspace will use SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
as commands to issue ioctl() to fill the 'snd_pcm_status' structure in
From: Baolin Wang
The struct snd_rawmidi_status will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Thus we introduced 'struct snd_rawmidi_status32' and 'struct
snd_rawmidi_status64'
to handle 32bit time_t and 64bit time_t in native mode, which
From: Baolin Wang
The struct snd_timer_tread will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Since the struct snd_timer_tread is passed through read() rather than
ioctl(), and the read syscall has no command number that lets us pick
between
On Tue, Nov 12, 2019 at 4:02 PM Amir Goldstein wrote:
>
> On Tue, Nov 12, 2019 at 4:16 PM Christoph Hellwig wrote:
> >
> > Amir just send another patch dealing with the time stamps. I'd suggest
> > you chime into the discussion in that thread.
>
> That's right I just posted the ext4 style
On Tue, 12 Nov 2019 16:16:36 +0100,
Arnd Bergmann wrote:
>
> From: Baolin Wang
>
> struct snd_timer_status uses 'timespec' type variables to record
> timestamp, which will be changed to an incompatible layout with
> updated user space using 64-bit time_t.
>
> To handle both the old and the new
On Tue, Nov 12, 2019 at 01:09:06PM +0100, Arnd Bergmann wrote:
> However, as long as two observations are true, a much simpler solution
> can be used:
>
> 1. xfsprogs is the only user space project that has a copy of this header
We can't guarantee that.
> 2. xfsprogs already has a replacement
Amir just send another patch dealing with the time stamps. I'd suggest
you chime into the discussion in that thread.
___
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
From: Baolin Wang
struct snd_timer_status uses 'timespec' type variables to record
timestamp, which will be changed to an incompatible layout with
updated user space using 64-bit time_t.
To handle both the old and the new layout on 32-bit architectures,
this patch introduces 'struct
This is a preparation patch, moving the compat handler for
snd_pcm_ioctl_sync_ptr_compat from pcm_compat.c to pcm_native.c.
No other changes are indented.
Signed-off-by: Baolin Wang
Signed-off-by: Arnd Bergmann
---
sound/core/pcm_compat.c | 98 --
From: Baolin Wang
The struct snd_ctl_elem_value will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Since there are no drivers will implemented the tstamp member of the
struct snd_ctl_elem_value, and also the stucture size will not be changed
if
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
On Fri, Nov 08, 2019 at 10:32:51PM +0100, Arnd Bergmann wrote:
> The interpretation of on-disk timestamps in HFS and HFS+ differs
> between 32-bit and 64-bit kernels at the moment. Use 64-bit timestamps
> consistently so apply the current 64-bit behavior everyhere.
>
> According to the official
On Tue, Nov 12, 2019 at 03:16:00PM +0100, Christoph Hellwig wrote:
> On Tue, Nov 12, 2019 at 01:09:06PM +0100, Arnd Bergmann wrote:
> > However, as long as two observations are true, a much simpler solution
> > can be used:
> >
> > 1. xfsprogs is the only user space project that has a copy of
> On Nov 9, 2019, at 12:32 AM, Arnd Bergmann wrote:
>
> The interpretation of on-disk timestamps in HFS and HFS+ differs
> between 32-bit and 64-bit kernels at the moment. Use 64-bit timestamps
> consistently so apply the current 64-bit behavior everyhere.
>
> According to the official
30 matches
Mail list logo
