Message-ID: <6410260.Js2exyRRNi@wuerfel>
Date:	Thu, 14 Jul 2016 13:39:13 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	y2038@...ts.linaro.org
Cc:	Deepa Dinamani <deepa.kernel@...il.com>,
	Albert ARIBAUD <albert.aribaud@...ev.fr>,
	libc-alpha@...rceware.org, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>
Subject: Re: [Y2038] Fourth draft of the Y2038 design document

On Wednesday, July 13, 2016 7:38:25 PM CEST Deepa Dinamani wrote:
> On Wed, Jul 13, 2016 at 1:40 PM, Deepa Dinamani <deepa.kernel@...il.com> wrote:

> >>> == 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.

Good point, I had forgotten how we discussed that a while ago.

> >>> 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.
> 
> Forgot to note one more thing here.
> Since we are already using struct sizes for ioctls, shouldn't this be similar.
> So optlen should also be okay?
> Just as in the example Arnd pointed out above:
> 
> /* Set and get port timeout (struct timeval's) */
> #define PPGETTIME       _IOR(PP_IOCTL, 0x95, struct timeval)
> #define PPSETTIME       _IOW(PP_IOCTL, 0x96, struct timeval)

I've added the netdev list and David Miller to Cc here, it seems
either way would work, and I don't have a strong preference.

a) add a flag to recvmsg() that glibc always passes when called
   using __USE_TIME_BITS64 to handle reading the timestamps, and
   rely on the optlen value for SO_RCVTIMEO/SO_SNTTIMEO to
   decide how to interpret the data

b) handle all five sockopts using conditional option numbers
   and don't rely on the recvmsg() flag or optlen.

Using either a) or b) is probably better than a combination of
them, so I've not listed that as another alternative.

To work around the header inclusion order problem we discussed
earlier for approach b), I suppose we can do this using
something like


#define SO_RCVTIMEO_TIME32	21
#define SO_RCVTIMEO_TIME64	53

#define SO_RCVTIMEO (__USE_TIME_BITS==64 ? SO_RCVTIMEO_TIME64 : SO_RCVTIMEO_TIME32)

where __USE_TIME_BITS is a macro defined by the libc. We cannot easily
check for whether a macro is defined in a conditional expression,
but I think the above should work, as long as we don't need use the
value from assembler code.

	Arnd

Powered by blists - more mailing lists