This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v9] y2038: Introduce the __ASSUME_TIME64_SYSCALLS define


On Wed, Sep 04, 2019 at 04:56:45PM +0200, Florian Weimer wrote:
> * Rich Felker:
> 
> >> If we give the padding a name, this will not work on big-endian targets
> >> 
> >>   ts?(struct timespec[]){ts->tv_sec, ts->tv_nsec}:0
> >> 
> >> because the padding is in the middle, and ts->tv_nsec is copied into the
> >> padding.
> >
> > While it may be desirable for compatibility with wrong code for this
> > sort of initializer to work, there is no specification on the order or
> > lack of other named members in timespec. Correct initialization has to
> > use designated initializers. I tried to sidestep the problem by using
> > *ts, but indeed I botched that; it would not zero the padding.
> 
> Wrong initializers are fairly common, unfortunately:
> 
> <https://codesearch.debian.net/search?q=struct+timespec.*+%3D+%5C%7B%5Cs*%5B%5E+.0%5D&literal=0&perpkg=1>

Indeed, I believe you on that. :-P

> >> If we do not give the padding a name, the expression leaves the padding
> >> uninitialized (C11: “Unnamed members of structure objects have
> >> indeterminate value even after initialization.”).
> >> 
> >> And who should do this?  I think for pselect, glibc has to do it, but
> >> what about ioctls and socket options?
> >
> > These need translation logic anyway or post-time64 software won't run
> > on pre-time64 kernels. See
> >
> > https://git.musl-libc.org/cgit/musl/commit/?id=51fd67fcbfa598e2fe1885b517451b84c0bfe3b7
> >
> > So it's not a big deal to also zero the padding if needed.
> 
> That's not in the patch, right?

I'm not aware of any equivalent proposed code for glibc. But in the
absence of it, there's a major disincentive to adopt _TIME_BITS=64
until pre-5.1 kernels are mostly gone, since certain functionality
that's been present for decades will suddenly disappear (behaving as
if unsupported).

> Is the set of emulations required fixed?  In the sense that there will
> be no new kernel features which are 32-bit only?

For the most part, yes -- it's sockopt/ioctl interfaces that used
timeval or timespec and that existed prior to time64 support. The only
place it might be unbounded is when out-of-tree special-purpose
drivers or other kernel modules define ioctl interfaces involving
these types, and get built for pre-5.1 kernels. IMO any breakage in
them is much less of a big deal and could probably be dealt with via
local hacks in the (usually hardware-specific) software, or (for
glibc) just always building the small amount of affected software with
_TIME_BITS=32 on 32-bit archs until old kernels are no longer
relevant.

> Only in that case, I think userspace emulation is feasible.  Getting
> full coverage for ioctls will still be difficult, I think.

Yes, I still don't know the scope of the ioctl problem. I've only
worked on the sockopts and ioctls that are for use with sockets.

> I wonder if we should define a proper type (with long long int members)
> for applications to use with ioctls.  That would enable concise syntax
> and documenting intent.
> 
> Or we could work with WG14 and POSIX and introduce a snseconds_t type,
> formally blessing what x32 and the kernel already do.  If we can get
> this changed, I'm not sure if supporting older C and POSIX standards
> (which mandate long) is worth the cost.

I think the kernel is already treating (or intending to treat) the
padding correctly here. (Can someone confirm this? Arnd?) The problem
is not the case where the kernel accepts time64 but needs help fixing
up the padding. The problem is the case where the kernel only supports
the old time32 version of the sockopt/ioctl and userspace has 64-bit
time_t.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]