From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116282 invoked by alias); 29 Jun 2016 13:28:24 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 116270 invoked by uid 89); 29 Jun 2016 13:28:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=raid, transmitted, y2038-safe, SO_RCVTIMEO X-HELO: mout.kundenserver.de From: Arnd Bergmann To: libc-alpha@sourceware.org Cc: Albert ARIBAUD , Y2038 Subject: Re: Fourth draft of the Y2038 design document Date: Wed, 29 Jun 2016 13:28:00 -0000 Message-ID: <8678062.LYkYXkqyIl@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160629115838.5019002a.albert.aribaud@3adev.fr> References: <20160622005838.60a95c44.albert.aribaud@3adev.fr> <4435377.8hJ2GQPYUg@wuerfel> <20160629115838.5019002a.albert.aribaud@3adev.fr> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-UI-Out-Filterresults: notjunk:1;V01:K0:euesBkbWyFw=:c9bAF2QlflVGX6mz7bCXtl Bu1aG82eIqzOndpeTOyaMkygprfUj54aWfIjAbct64Yl/FpsbYcNRaYcWR9NW96stY4MDxeBE cHSfiVVXhBncaKft17ZBPpFu6zy7Ekd4rvy/ckwYWE9we9cVXG6NeYa2DIyxkdCUzaeagV7gJ jUDL4r3HmlS8GHb7ESmKRU+nqH3QftBjSBfRXBkUQWzZzeynD70q/NV4CO68k3+sPRHjMLWHL P9AnoX3fVZxqdMLCtR4AU/l3EYNkW4IWvs5vSA4jUqNhl5AuYWqrVvjD9M1tcSzYwL667Vyw+ 3y3UHZNNRiN77bI2VJLVrhzsKOQOzbnWIvudzZPy/A32jE19JoZAqV/gT962PiHeDyvnzw0cp wEUs5sgR4NSkoLp2HO3e6tWu+cmqa6wiD0XoaNlNAgJ62IbBqOnkgm0Q3y4Y+IesJod63EEra +bmeg40iVVuLGzk6zZ4RL5tEXbA7qbYkAkp2Mpkd9jwnYSuwgmDiSq0bqQQDjYGZwvLWjSpiv Vk0BJsb6UDJz/azZvvVRcITtAg0J/6j0VFzVD3BxlAh8dynhdHBefwYXDMIsKJFzEQdF3ID+P pfSNXFEL0p9wFQmLmCV90KrdO7ZO/w9dvAMk7AuKqAMuQXbuPs1Q1Z1pJrf828gqWm6aLPydR v9a/fFNGnmARrVkFKBEB3xIuhrk19A7Y7s5QIYp7Mk8gQ5uSVYfuvpVtYb51s+97d1q9g/v37 8EYPfA8ZLVAqgLgG X-SW-Source: 2016-06/txt/msg01210.txt.bz2 On Wednesday, June 29, 2016 11:58:38 AM CEST Albert ARIBAUD wrote: > > == 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. a) include/linux/ppdev.h: /* Set and get port timeout (struct timeval's) */ #define PPGETTIME _IOR(PP_IOCTL, 0x95, struct timeval) #define PPSETTIME _IOW(PP_IOCTL, 0x96, struct timeval) b) include/linux/lp.h: (this passes a timeval as well) #define LPSETTIMEOUT 0x060f /* set parport timeout */ c) Actually I could not find a real case any more, it's possible they are all gone. Two similar cases though: linux/raid/md_u.h: (this one was "fixed" by ensuring the user space side can deal with 32-bit time stamps) typedef struct mdu_array_info_s { ... unsigned int utime; /* 0 Superblock update time */ ... } mdu_array_info_t; #define GET_ARRAY_INFO _IOR (MD_MAJOR, 0x11, mdu_array_info_t) drivers/staging/ft1000/ft1000-usb/ft1000_ioctl.h: (this file was removed since, as the hardware is now obsolete) struct IOCTL_GET_DSP_STAT { unsigned char DspVer[DSPVERSZ]; /* DSP version number */ unsigned char HwSerNum[HWSERNUMSZ]; /* Hardware Serial Number */ unsigned char Sku[SKUSZ]; /* SKU */ unsigned char eui64[EUISZ]; /* EUI64 */ unsigned short ConStat; /* Connection Status */ unsigned long nTxPkts; /* Number of packets transmitted * from host to dsp */ unsigned long nRxPkts; /* Number of packets received from * dsp to host */ unsigned long nTxBytes; /* Number of bytes transmitted * from host to dsp */ unsigned long nRxBytes; /* Number of bytes received from * dsp to host */ unsigned long ConTm; /* Current session connection time * in seconds */ .... } __packed; #define IOCTL_FT1000_GET_DSP_STAT _IOR(FT1000_MAGIC_CODE, \ IOCTL_GET_DSP_STAT_CMD, \ struct IOCTL_GET_DSP_STAT) > > == 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? Correct. > > 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. Fair enough. Arnd