On Friday 04 March 2016 12:10:08 Dave Chinner wrote: > On Thu, Mar 03, 2016 at 03:08:22PM +0100, Arnd Bergmann 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: > > > 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. > > Wrong way around, IMO. Set the defaults to be limiting first, then > as filesystems are converted the limits get expanded. That would break perfectly working 64-bit systems, along with 32-bit systems that have the new syscalls, unless we intentionally treat them differently. :( > > 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. > > Perhaps, but I'm yet to understand why we even care if filesystems > have set limits or not? If the filesystem has not set it's own > limits, then surely we should assume that the filesystem is not > y2038k compatible and have the default limits set appropriately for > that? I don't think we can make any such assumption. Out of the ~50 file systems that have store timestamps on disk or on the network, I only found eight that are use the 1902..2038 range that matches the 32-bit time_t. > > > 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). > > Yes, and that needs to be done when the filesystem is converted to > use the proper timespec64 representation. No, it's completely unrelated to the timespec64 change, other than the fact that you asked for the limits to be implemented as a result of the y2038 patch series. This is absolute reasonable because we are touching the same code, and we have to audit it anyway. > > 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. > > Yes, 32 bit tasks is something for the syscall layer to care about. > > But that doesn't change the fact that the *default timestamp range* > should be "no >y2038 support", and it is up to the filesystem to > override that with it's own limits if they are different. I still think the opposite approach makes more sense here: Right now, we have 64-bit systems that have file systems with arbitrary limitations working in random ways, most of them correctly supporting at least time stamps between 1970 and 2106, some of them much wider ranges. The 32-bit systems are currently all broken beyond 2038, and they have always been that way. Changing everything to use timespec64 brings 32-bit systems to the same level of functionality as 64-bit systems, and extends the maximum supported timestamp range to what each file system can store on disk. Adding the range checking ensures that we don't run into whatever limit a file system has in an uncontrolled way, but get a specific error, or controlled clamping of the range. We would need this even if all 32-bit systems would die out tomorrow and we only worried about 64-bit machines. > > On most 32-bit architectures, stat64 still has a 32-bit time value, > > and even if it is 64-bit wide, glibc turns it into a 32-bit > > number when copying to its version of 'struct stat64' that differs > > from the kernel's and contains a 'struct timespec'. > > So stat64 also returns EOVERLFOW to indicate to the application > that it needs to use a different, 64 bit time aware syscall. Right, except that for an application programmer this is not visible. The application won't be able to call a replacement system call, but it has to be built with -D_TIME_BITS=64 so all time_t uses get changed to 64-bit. I believe for LFS support, user space was allowed to call a stat64() glibc function, but that won't be provided here. > > I don't care if we return EOVERFLOW or give some other indication > > of the overflow, but this is fundamentally a separate problem from > > large file support, and we need a new syscall for it. > > Yes, but you seem to have missed my point that the we don't need to > care about 32 bit times, whether it be syscalls or tasks, at the > VFS/filesystem level. That's all a syscall layer issue. i.e. > vfs_fstatat() only uses 64 bit times and only places where struct > kstat contents get converted to whatever structure userspace has > supplied (e.g. cp_new_stat()) need to detect/care about timestamp > overflows like they already do with inode numbers and link counts. I think that was exactly the point I was making. Arnd -- 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
