From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934232AbcBDNbu (ORCPT ); Thu, 4 Feb 2016 08:31:50 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:63303 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932752AbcBDNbr (ORCPT ); Thu, 4 Feb 2016 08:31:47 -0500 From: Arnd Bergmann To: Ilya Dryomov , Alex Elder Cc: "Yan, Zheng" , Deepa Dinamani , Zheng Yan , linux-fsdevel@vger.kernel.org, y2038@lists.linaro.org, Dave Chinner , "Theodore Ts'o" , linux-kernel , Sage Weil , ceph-devel Subject: Re: [PATCH 09/10] fs: ceph: Replace CURRENT_TIME by ktime_get_real_ts() Date: Thu, 04 Feb 2016 14:31:35 +0100 Message-ID: <3114558.FPEUoEgqxL@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1454479670-8204-1-git-send-email-deepa.kernel@gmail.com> <4400939.hfiB5KsmnG@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:rAVd2tyWNKp/LCjYpLAOPScWcaVW7dg5KeTrN7MEypDZGy1BiWW g7B0+8Ws9U1c7spG9zCcCLQhXtxxbWnRLCC3La7Uxz9cy06GYTwmPQ+ajVV1DSprCDFs2B5 56Sl2aBRilGdcJrCyoqldl+RUDhjpg4ISRkpKhmdGPzUBK1SbmLskgaseRrJkeujDa3q8Y+ pXJ9Z/yPX86Zyx51/65Mg== X-UI-Out-Filterresults: notjunk:1;V01:K0:YrRQvEEC7xQ=:v/8GPUtSVC5V9CUJaaoXZj XKhnh1WOyWvus0FJ/7QSX5wD/vNXvvBePevfHvErS59bhB75mQTtGjHaIkbcVt4w5kZQX4qhl AAW6iKg67WLuaB9jcEQGICSFNGnAcR7K+anvbk64WwA3owE6nwlMyTWbVfi0BMCtTX3RVPO6O cWXfvKK8oB0iGmhUNeDHX88eMTAWwpGB+6VTYKEZ+vrq5JkQUoNsRONI5orOdS5nuLzS/k6Ad NQ9FJauDHcVnP5OGplwFzuGThGsdB47fxlRymaAdkV57s+i1HUYzp79KYeJOQ4MSsVt+V8B4T V7UTQP3Og+ffu2ckvMDb6JhFFG3ZyQEZxzNzutKwlGZQhDuqXJLhXyOeuYuSxQ5C4KjwT23sI rUt/0OovZwYq8qQfLhLEqfdG1PZFjuF8BfMNHchAGynJUsT3A62HFnkCN5O/zDXvrSIlpEyRF PMK589GlVJqkUx6HJt2h1zGN6hMLtqHaN9LOoExAlQeiFWm814jVRTchtFQBN2FzYETzBaaQA RD43nNu+MEtE4XauR0Oxyj3iGNBaILTps640tPEa+Xl6+Wren8EpRGMaNY7j9F+F59w9KBVhD lKahxyi4GA8uKh49TM5yEhst/lQsOnXuhzInk31M5h5kK8DedySUNtctt5o6K9cCpCNWOusqz 3iXjJ7PvCcE7ocKCfA9zKID/hi6uG/sOks9HeKq2rDr8wIS/SRHavPKracJDJnzMnD7/4505f NgXHjYmrLYKC62kQ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 04 February 2016 10:01:31 Ilya Dryomov wrote: > On Thu, Feb 4, 2016 at 9:30 AM, Arnd Bergmann wrote: > > On Thursday 04 February 2016 10:00:19 Yan, Zheng wrote: > >> > On Feb 4, 2016, at 05:27, Arnd Bergmann wrote: > > > > static inline void ceph_decode_timespec(struct timespec *ts, > > const struct ceph_timespec *tv) > > { > > ts->tv_sec = (__kernel_time_t)le32_to_cpu(tv->tv_sec); > > ts->tv_nsec = (long)le32_to_cpu(tv->tv_nsec); > > } > > > > Is that intentional and documented? If yes, what is your plan to deal > > with y2038 support? > > tv_sec is used as a time_t, so signed. The problem is that ceph_timespec is > not only passed over the wire, but is also stored on disk, part of quite a few > other data structures. That is only part of the issue though: Most file systems that store a timespec on disk define the function differently: static inline void ceph_decode_timespec(struct timespec *ts, const struct ceph_timespec *tv) { ts->tv_sec = (time_t)(u32)le32_to_cpu(tv->tv_sec); ts->tv_nsec = (long)le32_to_cpu(tv->tv_nsec); } On systems that have a 64-bit time_t, the 1902..1970 interval (0xffffffff80000000..0xffffffffffffffff) and the 2038..2106 interval (0x0000000080000000..0x00000000ffffffff) are written as the same 32-bit numbers, so when reading back you have to decide which interpretation you want, and your cast to __kernel_time_t means that you get the first representation on both 32-bit and 64-bit systems. On systems with a 32-bit time_t, this is the only option you have anyway, and some other file systems (ext2/3/4, xfs, ...) made the same decision in order to behave in a consistent way independent of what kernel (32-bit or 64-bit) you use. This is generally a reasonable goal, but it means that you get the overflow in 2038 rather than 2106. Alex Elder changed the cephs behavior in 2013 to be the same way, but from the changelog c3f56102f28d ("libceph: validate timespec conversions"), I guess this was not intentional, as he was also adding a comparison against U32_MAX, which should have been S32_MAX. A lot of other file systems (jfs, jffs2, hpfs, minix) apparently prefer the 1970..2106 interpretation of time values. > The plan is to eventually switch to a 64-bit tv_sec and > tv_nsec, bump the version on all the structures that contain it and add > a cluster-wide feature bit to deal with older clients. We've recently had > a discussion about this, so it may even happen in a not so distant future, but > no promises Ok. We have a (rough) plan to deal with file systems that don't support extended time stamps in the meantime, so depending on user preferences we would either allow them to be used as before with times clamped to the 2038 overflow date, or only mounted readonly for users that want to ensure their systems can survive without regressions in 2038. Arnd