Re: [Y2038] [PATCH 02/21] fs: ext4: Use current_fs_time() for inode timestamps

On Wed, Jun 8, 2016 at 10:04 PM, Deepa Dinamani wrote: > CURRENT_TIME_SEC and CURRENT_TIME are not y2038 safe. > current_fs_time() will be transitioned to be y2038 safe > along with vfs. > > current_fs_time() returns timestamps according to the > granularities set in the

Re: [Y2038] [PATCH 01/21] fs: Replace CURRENT_TIME_SEC with current_fs_time()

On Thu, Jun 9, 2016 at 12:35 AM, Jan Kara wrote: > > You create line longer than 80 characters for affs and reiserfs. Please > wrap those lines properly. No, please do *NOT* do things like that. These kind of mechanical patches should (a) be as mechanical as possible (and see

Re: [Y2038] [PATCH v2 00/24] Delete CURRENT_TIME and CURRENT_TIME_SEC macros

On Sun, Jun 19, 2016 at 5:26 PM, Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. This version now looks ok to me. I do have a comment (or maybe just a RFD) for future work. It does strike me that once we

Re: [Y2038] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

On Thu, Jun 9, 2016 at 1:38 PM, Deepa Dinamani wrote: > > 1. There are a few link, rename functions which assign times like this: > > - inode->i_ctime = dir->i_ctime = dir->i_mtime = CURRENT_TIME; > + inode->i_ctime = dir->i_ctime = dir->i_mtime = >

Re: [Y2038] [PATCH 04/21] fs: Replace CURRENT_TIME with current_fs_time() for inode timestamps

On Wed, Jun 8, 2016 at 10:04 PM, Deepa Dinamani wrote: > CURRENT_TIME macro is not appropriate for filesystems as it > doesn't use the right granularity for filesystem timestamps. > Use current_fs_time() instead. Again - using the inode instead fo the syuperblock in tghis

Re: [Y2038] [PATCH v5 0/5] Introduce current_time() api

On Wed, Sep 14, 2016 at 7:48 AM, Deepa Dinamani wrote: > The series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. > The macros are not y2038 safe. There is no plan to transition them into being > y2038 safe. This version looks ok to me. Al,

Re: [Y2038] [PATCH v5 2/5] vfs: Add checks for filesystem timestamp limits

On Sat, Apr 8, 2017 at 12:37 PM, Deepa Dinamani wrote: > Allow read only mounts for filesystems that do not > have maximum timestamps beyond the y2038 expiry > timestamp. This option seems arbitrary and pointless. Nobody sane should ever enable it except for testing, but

Re: [Y2038] [PATCH v5 2/5] vfs: Add checks for filesystem timestamp limits

On Tue, Apr 25, 2017 at 1:31 PM, Arnd Bergmann wrote: > > Would it be ok to have a simple way of removing the time_t definition (e.g. > by passing '-DREQUIRE_TIME64' to the compiler, but without the Kconfig > option? That way, someone who wants to ship a product can at least > find

Re: [Y2038] [PATCH v5 2/5] vfs: Add checks for filesystem timestamp limits

On Tue, Apr 25, 2017 at 12:47 PM, Arnd Bergmann wrote: > > There is one global option that I want to see, and that is for completely > disabling all components that are known to be broken in y2038. I really don't see the point. Don't do it. Make it some local hack, I'm not taking

Re: [Y2038] [PATCH v6 3/4] vfs: Add timestamp_truncate() api

On Sun, Jan 21, 2018 at 6:04 PM, Deepa Dinamani wrote: > + t.tv_nsec -= t.tv_nsec % gran; This doesn't actuall ywork if tv_nsec is negative. Which may not be an issue in most cases, but did somebody check utimensat() or whatever? > + WARN(1,