On Thu, Mar 3, 2016 at 8:08 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Thursday 03 March 2016 10:45:11 Dave Chinner wrote: >> On Thu, Mar 03, 2016 at 12:07:42AM +0100, Arnd Bergmann wrote: >> > On Thursday 03 March 2016 09:19:05 Dave Chinner wrote: >> > > On Wed, Mar 02, 2016 at 07:51:34AM -0800, Deepa Dinamani wrote: > >> > > > --- a/include/linux/fs.h >> > > > +++ b/include/linux/fs.h >> > > > @@ -927,6 +927,12 @@ static inline struct file *get_file(struct file *f) >> > > > #define MAX_LFS_FILESIZE ((loff_t)0x7fffffffffffffffLL) >> > > > #endif >> > > > >> > > > +#define MAX_VFS_TIME S64_MAX >> > > > +#define MIN_VFS_TIME S64_MIN >> > > >> > > These. Anything ouside these ranges is invalid. >> > > >> > > As such, I think this is wrong for 32 bit systems as the min/max VFS >> > > times right now are S32_MAX/S32_MIN... >> > >> > I think the file system should always set the actual on-disk format >> > limits in the superblock, regardless of the word size of the CPU >> > architecture. >> >> Eventually, yes. But right now, 32 bit systems are limited by the >> platform architecture. Hence no matter what the filesystem on-disk >> format supports, these are going to hard limits until filesystems >> start modifying the defaults to indicate what their on-disk format >> supports. > > The purpose of the patch for now is to allow file systems to set > the defaults, we are not checking them yet, until all file systems > are converted, hence setting the defaults to invalid. > > Our initial idea was to set the defaults for minimum and maximum > to zero, which would have made this clearer, but unfortunately > that doesn't allow us to detect whether a file system actually > supports time stamps at all: some file systems hardcode all > timestamps to zero (1970) because they don't store them on disk. > > How about setting the defaults for minimum and maximum to '-1'? > That would allow us to detect whether file systems have set > this correctly, and it would be less confusing to the reader. > >> i.e. 32 bit systems should default to 32 bit time limits until the >> filesystem developers come along and verify that conversion from >> their on-disk format to 64 bit time works correctly. Then they set >> their real limits which may (or may not) be >y2038 compatible, and >> this means that filesystems that have not been converted to >y2038 >> compatible do not need any modifications to behave correctly on 32 >> bit systems... > > We can set the limits in the superblock if you like, but I would > not do it by changing the constants here: > > Most file systems have arbitrary other maximum dates that they > need to set (on 64-bit systems), e.g. 2028 (iso9660), 2040 (hfsplus), > 2106 (ceph), 2107 (fat, cifs), 2262 (logfs), 2514 (ext4). I am puzzled why 2107 would be the maximum date for cifs. My calculation comes to a maximum date of approximately the year 60,000AD for 64 bit DCE time (cifs.ko gets DCE time back in all time fields when using CIFS, SMB2 or SMB3 except for the oldest dialects of CIFS). DCE time is 100 nanoseconds since 1601 - see the definition of FILETIME in section 2.3.3 of https://msdn.microsoft.com/en-us/library/cc230324.aspx). And shouldn't this be the same for NTFS as they use a similar DCE time internally? > The file systems specific code should just set whatever it actually > supports and then we can find a way to limit that further for > 32-bit tasks. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
