From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753374AbcAOC1j (ORCPT ); Thu, 14 Jan 2016 21:27:39 -0500 Received: from ipmail05.adl6.internode.on.net ([150.101.137.143]:38657 "EHLO ipmail05.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753110AbcAOC1h (ORCPT ); Thu, 14 Jan 2016 21:27:37 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2DECQAZWJhWPGwtLHleKAECgw+BP4Jkg3uBeZ9nBotbiUOGCQQCAoE8TQEBAQEBAQcBAQEBQAE/QQ6DZgEBBDocIxAIAxgJJQ8FJQMHGhOIKMEJAQEBAQYCASAYhXWFR4k9BZcWjVKBZ4dvhTSDSIsPhQIqNIQnggoBAQE Date: Fri, 15 Jan 2016 13:27:34 +1100 From: Dave Chinner To: Arnd Bergmann 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 Message-ID: <20160115022733.GL6033@dastard> References: <1452144972-15802-1-git-send-email-deepa.kernel@gmail.com> <20160114210000.GK6033@dastard> <4096827.pGyVFmGqbD@wuerfel> <4774139.hV6lmEpfqG@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4774139.hV6lmEpfqG@wuerfel> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. Users can then make the decision when mounting their filesystems. If they are system/automatically mounted filesystems and aren't y2038k compliant, then the override option can be added to /etc/fstab and we're all good. If the truly paranoid users want to disallow the override and/or read only mount options, then add a sysctl to control that. Cheers, Dave. -- Dave Chinner david@fromorbit.com