This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Y2038] Fourth draft of the Y2038 design document
- From: Deepa Dinamani <deepa dot kernel at gmail dot com>
- To: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- Cc: Arnd Bergmann <arnd at arndb dot de>, Y2038 <y2038 at lists dot linaro dot org>, libc-alpha at sourceware dot org
- Date: Wed, 13 Jul 2016 13:40:08 -0700
- Subject: Re: [Y2038] Fourth draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20160622005838.60a95c44.albert.aribaud@3adev.fr> <4435377.8hJ2GQPYUg@wuerfel> <20160629115838.5019002a.albert.aribaud@3adev.fr>
>> I think we should expand the ioctl section a bit: I can do most of it
>> in the kernel, but need help from glibc for a few things in which we
>> need to agree on calling conventions. Here is what I'd suggest having in
>> the document, feel free to take that into your document or edit as you
>> wish:
>>
>> == IOCTLs and Y2038 ==
>>
>> Some Linux IOCTLs may be Y2038-unsafe, or use types defined by glibc
>> that do not match the kernel internal types. Known important cases are:
>>
>> - An ioctl command number is defined using the _IOR/_IOW/_IORW macros
>> by the kernel with a structure whose size changes based on glibc's
>> time_t. The kernel can handle these transparently by implementing
>> handlers for both command numbers with the correct structure format.
>>
>> - The binary ABI changes based on the glibc time_t type, but the
>> command number does not change. In this case, the kernel header files
>> defining the data structure will check the "__USE_TIME_BITS64"
>> macro [do we need a new macro for the kernel headers?] to provide
>> a different command number for the new data structure layout. glibc
>> will define this macro at an appropriate location [where?] to make
>> it visible before including kernel header files.
>>
>> - An ioctl command passes time information in a structure that is not
>> based on time_t but another integer type that does not get changed.
>> The kernel header files will provide both a new structure layout
>> and command number when "__USE_TIME_BITS64" is set.
>>
>> [I can find examples for ioctl commands in each of those
>> categories if needed.]
>
> Please do -- I understand the first two cases, but I am not sure I
> understand the third one.
>
>> == Socket options ==
>>
>> Like ioctl(), setsockopt()/getsockopt() has a few interfaces that are
>> passing time data:
>>
>> SO_TIMESTAMP/SO_TIMESTAMPNS/SO_TIMESTAMPING: These enable the
>> timestamping infrastructure for a socket, which will consecutively
>> return data to user space using "cmsg" data on the socket. The kernel
>> does not know the layout of 'struct timespec' and 'struct timeval'
>> when filling the cmsg data, so we need to define new binary values
>> for the three flags, which then get used if __USE_TIME_BITS64
>> is set.
>
> IOW, introduce three new optname values (say 51, 52, and 53 as on my
> machine, /usr/include/asm-generic/socket.h stops at 50 right now) that
> would behave similar to options 29, 35 and 37 but would use Y2038-safe
> timestamps; and define option names SO_TIMESTAMP, SO_TIMESTAMPNS and
> SO_TIMESTAMPING to be either 29, 35 and 37 (the Y2038-unsafe options) or
> 51, 52 and 53 (the Y2038-safe ones) depending on __USE_TIME_BITS64.
> Right?
Another way of handling this would be to use the flags in sendmsg/recvmsg.
Since cmsg is sent using these calls, at the time of call, sendmsg/recvmsg can
indicate whether 64 bit time_t or 32 bit time_t is used.
This will eliminate the need for new options and kernel need not depend on
__USE_TIME_BITS64.
>> SO_RCVTIMEO/SO_SNTTIMEO: These pass a 'struct timeval' and a length.
>> Assuming that the 'optlen' argument of the setsockopt syscall always
>> matches the size of 'struct timeval', the kernel will be able to
>> access the data in the same format that was passed by glibc. [alternatively,
>> we could handle this the same way as SO_TIMESTAMP*, using new numbers
>> for the flags].
>
> I would prefer new numbers, that's more explicit and slightly safer,
> as if we rely on optlen, Murphy's Law will see to it that in practice
> it will have the wrong value.
But, if we are not using optlen here, then probably just using new numbers for
timestamps also makes sense.
-Deepa