From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754102AbcAORBo (ORCPT ); Fri, 15 Jan 2016 12:01:44 -0500 Received: from mout.kundenserver.de ([212.227.126.187]:50852 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753917AbcAORBl (ORCPT ); Fri, 15 Jan 2016 12:01:41 -0500 From: Arnd Bergmann To: Dave Chinner Cc: y2038@lists.linaro.org, linux-fsdevel@vger.kernel.org, Deepa Dinamani , linux-kernel@vger.kernel.org Subject: Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time Date: Fri, 15 Jan 2016 18:01:36 +0100 Message-ID: <7254587.VgG2py0ZUI@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160115022733.GL6033@dastard> References: <1452144972-15802-1-git-send-email-deepa.kernel@gmail.com> <4774139.hV6lmEpfqG@wuerfel> <20160115022733.GL6033@dastard> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:67Kny0pTlmbETPjRLsFnThmk5b2sGTgLcoLN2t/PaQPwme4c9li mlvf2fPSPpGlt+KIW8j4J8gmrCmVZkxIMLBQ+qh+EFt5oq4zeNdpazWY3i8w3yxoDYT2LI3 3lHDeBTztETzpYZTSiuo3qd1h46gtMiB3c404pC4T5cImAt84Ycyg/+6Ug/3kCxUxdw1B3E 5x8MIb9H1vJWXnVAltnJA== X-UI-Out-Filterresults: notjunk:1;V01:K0:O9EbQDj/DcE=:e05jCyDYe8ZRjrzHoL0MgN Ueooz7UhqjGnFgIU83vw4q5lSJmiapVqrvNU+PRBIm/rziGcM1QE1HvARFQqMXIw4yEJeY1cx 3cZqO0wfDJvR0lVcTm5GNS3hfj5CZcefCKC6WYTEE7tJU/w3J4/UXKPelPgzp3wGvgM03RuNm kIe2YfyDDX4O1JXHdMv/9CCDCVvlkHrJvZQ4w96FYYPeiGstOIeyCMB6cOG6pJqwitDkhfj1x 3pK87+LdjybvivN+rDoKMxWy0gz2jmk7ZoYuhBHqImR8ZIYn2ON/zLJaHyPc2PuuykpFQL/8H G9nfi4UgVEiYA/h8eVH0MHLQMZTCVa1AGqMmuvrVxUTTMrfakQ6ilh7JORyu62TcZ0cvwgidO +uIzlVZmRVn4m1HSfZVaWxA03IBQcTGH5zhy4/1OmPyyP+CqEqpNd9ZjGHWKmnpva3nZpdQ6i 01JU6Dj55Jtk0oPPLPX6TuVs6DrW+ghx3delDszQPJvL7u9qRd+6PeNxIhzUd7Za26E3QroWM 1fjpuMh/5pTNo/twZDqbVcT8Mk2B9Dxkx3P78PcMSxhXM/oiQGbtQIyaLFUlw1ZP+0NlT/i9i qYlJncv/RJ4lp9a3PDKH2depYD6xrPPYNBnenxyks4GIpDQb9Pf5wij3SHtkI1QHD4icCbLia nypVEtXNSWeRoelUbUsF+8gMWZqo1OGfbFOtS9s5L/ovTnfOJRuWt+YI5Kg5UYR3p9eDxRT/3 A8cFsEyvLKqsg+lw Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 15 January 2016 13:27:34 Dave Chinner wrote: > On Thu, Jan 14, 2016 at 11:54:36PM +0100, Arnd Bergmann wrote: > > On Thursday 14 January 2016 23:46:16 Arnd Bergmann wrote: > > > > > > I'm not following the line of thought here. We have some users > > > that want ext4 to mount old file system images without long > > > inodes writable, because they don't care about the 2038 problem. > > > We also have other users that want to force the same file system > > > image to be read-only because they want to ensure that it does > > > not stop working correctly when the time overflow happens while > > > the fs is mounted. > > > > > > If you don't want a compile-time option for it, how do you suggest > > > we decide which case we have? > > > > In case that came across wrong, I'm assuming that the first > > user also wants all the system calls enabled that pass 32-bit > > time_t values, while the second one wants them all left out from > > the kernel to ensure that no user space program gets incorrect > > data. > > system call API support is a completely different class of problem. > It's out of the scope of this patchset, and really I don't care what > you do with them. Sure, I was just providing some background about why we want a compile-time option in general. > The point I'm making is that we'll have to modify all the existing > filesystem code to supply a valid timestamp range to the VFS at > mount time for the range checking/clamping, similar to how we do the > granularity specification right now. That means we can do rejection > of non-y2038k compliant filesystems at runtime based on what the > filesystem tells the VFS it supports.. Set up the default to be > reject if rw, allow if ro, and provide a mount option to override ad > allow mounting rw. We can't really default to "reject if rw", because that would break all systems using ext3 or xfs, unless users modify their fstab or set the flag that makes the partition y2038 compliant. The compile-time option that I'm thinking of would change the default beween "always allow" and "reject if rw", based on whether the system cares about this issue or not. Almost everyone today won't care about it at all and would be rather annoyed by being unable to mount their rootfs, but some people care about the behavior a lot. Having a global sysctl or mount option as an override would be good, maybe both if that isn't over-engineering the problem when we already have a compile-time option. Arnd