* [PATCH v2 0/6] Delete timespec64_trunc() @ 2019-12-03 5:19 Deepa Dinamani 2019-12-03 5:19 ` [PATCH v2 2/6] fs: cifs: Delete usage of timespec64_trunc Deepa Dinamani 2019-12-06 2:43 ` [PATCH v2 0/6] Delete timespec64_trunc() Deepa Dinamani 0 siblings, 2 replies; 7+ messages in thread From: Deepa Dinamani @ 2019-12-03 5:19 UTC (permalink / raw) To: viro, linux-kernel Cc: linux-fsdevel, arnd, ceph-devel, hirofumi, jlayton, linux-cifs, linux-mtd, richard, stfrench This series aims at deleting timespec64_trunc(). There is a new api: timestamp_truncate() that is the replacement api. The api additionally does a limits check on the filesystem timestamps. The suggestion to open code some of the truncate logic came from Al Viro. And, this does make the code in some filesystems easy to follow. The series also does some update_time() cleanup as suggested by Al Viro. Deepa Dinamani (6): fs: fat: Eliminate timespec64_trunc() usage fs: cifs: Delete usage of timespec64_trunc fs: ceph: Delete timespec64_trunc() usage fs: ubifs: Eliminate timespec64_trunc() usage fs: Delete timespec64_trunc() fs: Do not overload update_time fs/ceph/mds_client.c | 4 +--- fs/cifs/inode.c | 13 +++++++------ fs/fat/misc.c | 10 +++++++++- fs/inode.c | 33 +++------------------------------ fs/ubifs/sb.c | 11 ++++------- include/linux/fs.h | 1 - 6 files changed, 24 insertions(+), 48 deletions(-) -- Changes since v1: * Dropped the atime comparison (patch 2/7) taken through cifs tree. * Refactored update_time according to review comments. 2.17.1 Cc: ceph-devel@vger.kernel.org Cc: hirofumi@mail.parknet.co.jp Cc: jlayton@kernel.org Cc: linux-cifs@vger.kernel.org Cc: linux-mtd@lists.infradead.org Cc: richard@nod.at Cc: stfrench@microsoft.com ^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH v2 2/6] fs: cifs: Delete usage of timespec64_trunc 2019-12-03 5:19 [PATCH v2 0/6] Delete timespec64_trunc() Deepa Dinamani @ 2019-12-03 5:19 ` Deepa Dinamani 2019-12-06 2:43 ` [PATCH v2 0/6] Delete timespec64_trunc() Deepa Dinamani 1 sibling, 0 replies; 7+ messages in thread From: Deepa Dinamani @ 2019-12-03 5:19 UTC (permalink / raw) To: viro, linux-kernel; +Cc: linux-fsdevel, arnd, stfrench, linux-cifs timestamp_truncate() is the replacement api for timespec64_trunc. timestamp_truncate() additionally clamps timestamps to make sure the timestamps lie within the permitted range for the filesystem. Truncate the timestamps in the struct cifs_attr at the site of assignment to inode times. This helps us use the right fs api timestamp_trucate() to perform the truncation. Also update the ktime_get_* api to match the one used in current_time(). This allows for timestamps to be updated the same way always. Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Cc: stfrench@microsoft.com Cc: linux-cifs@vger.kernel.org --- fs/cifs/inode.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c index ca76a9287456..026ed49e8aa4 100644 --- a/fs/cifs/inode.c +++ b/fs/cifs/inode.c @@ -113,6 +113,7 @@ cifs_revalidate_cache(struct inode *inode, struct cifs_fattr *fattr) } /* revalidate if mtime or size have changed */ + fattr->cf_mtime = timestamp_truncate(fattr->cf_mtime, inode); if (timespec64_equal(&inode->i_mtime, &fattr->cf_mtime) && cifs_i->server_eof == fattr->cf_eof) { cifs_dbg(FYI, "%s: inode %llu is unchanged\n", @@ -162,6 +163,9 @@ cifs_fattr_to_inode(struct inode *inode, struct cifs_fattr *fattr) cifs_revalidate_cache(inode, fattr); spin_lock(&inode->i_lock); + fattr->cf_mtime = timestamp_truncate(fattr->cf_mtime, inode); + fattr->cf_atime = timestamp_truncate(fattr->cf_atime, inode); + fattr->cf_ctime = timestamp_truncate(fattr->cf_ctime, inode); /* we do not want atime to be less than mtime, it broke some apps */ if (timespec64_compare(&fattr->cf_atime, &fattr->cf_mtime) < 0) inode->i_atime = fattr->cf_mtime; @@ -329,8 +333,7 @@ cifs_create_dfs_fattr(struct cifs_fattr *fattr, struct super_block *sb) fattr->cf_mode = S_IFDIR | S_IXUGO | S_IRWXU; fattr->cf_uid = cifs_sb->mnt_uid; fattr->cf_gid = cifs_sb->mnt_gid; - ktime_get_real_ts64(&fattr->cf_mtime); - fattr->cf_mtime = timespec64_trunc(fattr->cf_mtime, sb->s_time_gran); + ktime_get_coarse_real_ts64(&fattr->cf_mtime); fattr->cf_atime = fattr->cf_ctime = fattr->cf_mtime; fattr->cf_nlink = 2; fattr->cf_flags = CIFS_FATTR_DFS_REFERRAL; @@ -609,10 +612,8 @@ cifs_all_info_to_fattr(struct cifs_fattr *fattr, FILE_ALL_INFO *info, if (info->LastAccessTime) fattr->cf_atime = cifs_NTtimeToUnix(info->LastAccessTime); - else { - ktime_get_real_ts64(&fattr->cf_atime); - fattr->cf_atime = timespec64_trunc(fattr->cf_atime, sb->s_time_gran); - } + else + ktime_get_coarse_real_ts64(&fattr->cf_atime); fattr->cf_ctime = cifs_NTtimeToUnix(info->ChangeTime); fattr->cf_mtime = cifs_NTtimeToUnix(info->LastWriteTime); -- 2.17.1 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v2 0/6] Delete timespec64_trunc() 2019-12-03 5:19 [PATCH v2 0/6] Delete timespec64_trunc() Deepa Dinamani 2019-12-03 5:19 ` [PATCH v2 2/6] fs: cifs: Delete usage of timespec64_trunc Deepa Dinamani @ 2019-12-06 2:43 ` Deepa Dinamani 2019-12-07 6:02 ` Al Viro 1 sibling, 1 reply; 7+ messages in thread From: Deepa Dinamani @ 2019-12-06 2:43 UTC (permalink / raw) To: Alexander Viro, Linux Kernel Mailing List, Andrew Morton Cc: Linux FS-devel Mailing List, Arnd Bergmann, ceph-devel, OGAWA Hirofumi, Jeff Layton, CIFS, linux-mtd, Richard Weinberger, Steve French On Mon, Dec 2, 2019 at 9:20 PM Deepa Dinamani <deepa.kernel@gmail.com> wrote: > This series aims at deleting timespec64_trunc(). > There is a new api: timestamp_truncate() that is the > replacement api. The api additionally does a limits > check on the filesystem timestamps. Al/Andrew, can one of you help merge these patches? Thanks, -Deepa ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 0/6] Delete timespec64_trunc() 2019-12-06 2:43 ` [PATCH v2 0/6] Delete timespec64_trunc() Deepa Dinamani @ 2019-12-07 6:02 ` Al Viro 2019-12-08 2:04 ` Deepa Dinamani 0 siblings, 1 reply; 7+ messages in thread From: Al Viro @ 2019-12-07 6:02 UTC (permalink / raw) To: Deepa Dinamani Cc: Linux Kernel Mailing List, Andrew Morton, Linux FS-devel Mailing List, Arnd Bergmann, ceph-devel, OGAWA Hirofumi, Jeff Layton, CIFS, linux-mtd, Richard Weinberger, Steve French On Thu, Dec 05, 2019 at 06:43:26PM -0800, Deepa Dinamani wrote: > On Mon, Dec 2, 2019 at 9:20 PM Deepa Dinamani <deepa.kernel@gmail.com> wrote: > > This series aims at deleting timespec64_trunc(). > > There is a new api: timestamp_truncate() that is the > > replacement api. The api additionally does a limits > > check on the filesystem timestamps. > > Al/Andrew, can one of you help merge these patches? Looks sane. Could you check if #misc.timestamp looks sane to you? One thing that leaves me scratching head is kernfs - surely we are _not_ limited by any external layouts there, so why do we need to bother with truncation? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 0/6] Delete timespec64_trunc() 2019-12-07 6:02 ` Al Viro @ 2019-12-08 2:04 ` Deepa Dinamani 2019-12-08 3:04 ` Al Viro 0 siblings, 1 reply; 7+ messages in thread From: Deepa Dinamani @ 2019-12-08 2:04 UTC (permalink / raw) To: Al Viro Cc: Linux Kernel Mailing List, Andrew Morton, Linux FS-devel Mailing List, Arnd Bergmann, ceph-devel, OGAWA Hirofumi, Jeff Layton, CIFS, linux-mtd, Richard Weinberger, Steve French On Fri, Dec 6, 2019 at 10:02 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > On Thu, Dec 05, 2019 at 06:43:26PM -0800, Deepa Dinamani wrote: > > On Mon, Dec 2, 2019 at 9:20 PM Deepa Dinamani <deepa.kernel@gmail.com> wrote: > > > This series aims at deleting timespec64_trunc(). > > > There is a new api: timestamp_truncate() that is the > > > replacement api. The api additionally does a limits > > > check on the filesystem timestamps. > > > > Al/Andrew, can one of you help merge these patches? > > Looks sane. Could you check if #misc.timestamp looks sane to you? Yes, that looks sane to me. > One thing that leaves me scratching head is kernfs - surely we > are _not_ limited by any external layouts there, so why do we > need to bother with truncation? I think I was more pedantic then, and was explicitly truncating times before assignment to inode timestamps. But, Arnd has since coached me that we should not introduce things to safe guard against all possibilities, but only what is needed currently. So this kernfs truncate is redundant, given the limits and the granularity match vfs timestamp representation limits. -Deepa ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 0/6] Delete timespec64_trunc() 2019-12-08 2:04 ` Deepa Dinamani @ 2019-12-08 3:04 ` Al Viro 2019-12-09 0:48 ` Al Viro 0 siblings, 1 reply; 7+ messages in thread From: Al Viro @ 2019-12-08 3:04 UTC (permalink / raw) To: Deepa Dinamani Cc: Linux Kernel Mailing List, Andrew Morton, Linux FS-devel Mailing List, Arnd Bergmann, ceph-devel, OGAWA Hirofumi, Jeff Layton, CIFS, linux-mtd, Richard Weinberger, Steve French On Sat, Dec 07, 2019 at 06:04:38PM -0800, Deepa Dinamani wrote: > On Fri, Dec 6, 2019 at 10:02 PM Al Viro <viro@zeniv.linux.org.uk> wrote: > > > > On Thu, Dec 05, 2019 at 06:43:26PM -0800, Deepa Dinamani wrote: > > > On Mon, Dec 2, 2019 at 9:20 PM Deepa Dinamani <deepa.kernel@gmail.com> wrote: > > > > This series aims at deleting timespec64_trunc(). > > > > There is a new api: timestamp_truncate() that is the > > > > replacement api. The api additionally does a limits > > > > check on the filesystem timestamps. > > > > > > Al/Andrew, can one of you help merge these patches? > > > > Looks sane. Could you check if #misc.timestamp looks sane to you? > > Yes, that looks sane to me. > > > One thing that leaves me scratching head is kernfs - surely we > > are _not_ limited by any external layouts there, so why do we > > need to bother with truncation? > > I think I was more pedantic then, and was explicitly truncating times > before assignment to inode timestamps. But, Arnd has since coached me > that we should not introduce things to safe guard against all > possibilities, but only what is needed currently. So this kernfs > truncate is redundant, given the limits and the granularity match vfs > timestamp representation limits. OK... I've tossed a followup removing the truncation from kernfs; the whole series looks reasonably safe, but I don't think it's urgent enough to even try getting it merged before -rc1. So here's what I'm going to do: immediately after -rc1 it gets renamed[*] to #imm.timestamp, which will be in the never-modified mode, in #for-next from the very begining and safe for other trees to pull. Current shortlog: Al Viro (1): kernfs: don't bother with timestamp truncation Amir Goldstein (1): utimes: Clamp the timestamps in notify_change() Deepa Dinamani (6): fs: fat: Eliminate timespec64_trunc() usage fs: cifs: Delete usage of timespec64_trunc fs: ceph: Delete timespec64_trunc() usage fs: ubifs: Eliminate timespec64_trunc() usage fs: Delete timespec64_trunc() fs: Do not overload update_time Diffstat: fs/attr.c | 23 +++++++++++------------ fs/ceph/mds_client.c | 4 +--- fs/cifs/inode.c | 13 +++++++------ fs/configfs/inode.c | 9 +++------ fs/f2fs/file.c | 18 ++++++------------ fs/fat/misc.c | 10 +++++++++- fs/inode.c | 33 +++------------------------------ fs/kernfs/inode.c | 6 +++--- fs/ntfs/inode.c | 18 ++++++------------ fs/ubifs/file.c | 18 ++++++------------ fs/ubifs/sb.c | 11 ++++------- fs/utimes.c | 4 ++-- include/linux/fs.h | 1 - 13 files changed, 61 insertions(+), 107 deletions(-) [*] right now it's based on v5.4; I don't see anything that would warrant rebasing it to -rc1 at the moment, but if anything of that sort shows up tomorrow, s/renamed/rebased to -rc1 and renamed/. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2 0/6] Delete timespec64_trunc() 2019-12-08 3:04 ` Al Viro @ 2019-12-09 0:48 ` Al Viro 0 siblings, 0 replies; 7+ messages in thread From: Al Viro @ 2019-12-09 0:48 UTC (permalink / raw) To: Deepa Dinamani Cc: Linux Kernel Mailing List, Andrew Morton, Linux FS-devel Mailing List, Arnd Bergmann, ceph-devel, OGAWA Hirofumi, Jeff Layton, CIFS, linux-mtd, Richard Weinberger, Steve French On Sun, Dec 08, 2019 at 03:04:07AM +0000, Al Viro wrote: > OK... I've tossed a followup removing the truncation from kernfs; > the whole series looks reasonably safe, but I don't think it's urgent > enough to even try getting it merged before -rc1. So here's what > I'm going to do: immediately after -rc1 it gets renamed[*] to #imm.timestamp, > which will be in the never-modified mode, in #for-next from the very > begining and safe for other trees to pull. Rebased to -rc1, pushed out as #imm.timestamp, included into #for-next. Never-modified mode... ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-12-09 0:48 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-12-03 5:19 [PATCH v2 0/6] Delete timespec64_trunc() Deepa Dinamani 2019-12-03 5:19 ` [PATCH v2 2/6] fs: cifs: Delete usage of timespec64_trunc Deepa Dinamani 2019-12-06 2:43 ` [PATCH v2 0/6] Delete timespec64_trunc() Deepa Dinamani 2019-12-07 6:02 ` Al Viro 2019-12-08 2:04 ` Deepa Dinamani 2019-12-08 3:04 ` Al Viro 2019-12-09 0:48 ` Al Viro
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).