Al, Are you ok with this approach to changing vfs timestamps?
Kees mentioned that he wants to merge a patch to pstore that changes it to use timespec64 internally for 4.17: https://lkml.org/lkml/2018/5/13/3 I'm not sure how we usually merge such flag day patches. Should this be targeted for 4.17 or 4.18? The above might or might not be a problem based on when this series is merged. If you are ok with this approach, I could post a v2 with a couple of requested fix-ups. -Deepa On Fri, May 11, 2018 at 11:44 PM, Kees Cook <keesc...@chromium.org> wrote: > On Fri, May 11, 2018 at 9:59 PM, Deepa Dinamani <deepa.ker...@gmail.com> > wrote: >> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c >> index 5fcb845b9fec..fb681d302bb3 100644 >> --- a/fs/pstore/inode.c >> +++ b/fs/pstore/inode.c >> @@ -392,7 +392,7 @@ int pstore_mkfile(struct dentry *root, struct >> pstore_record *record) >> inode->i_private = private; >> >> if (record->time.tv_sec) >> - inode->i_mtime = inode->i_ctime = record->time; >> + inode->i_mtime = inode->i_ctime = >> timespec_to_timespec64(record->time); >> >> d_add(dentry, inode); > > I'm fine to just convert pstore internally to timespec64 right now. Is > it correct to say that I should use timespec64_to_timespec() here > until this flag day patch? And I'd need to do this as well, yes? > > fs/pstore/platform.c: record->time = > ns_to_timespec64(ktime_get_real_fast_ns()); > > Thanks! > > -Kees > > -- > Kees Cook > Pixel Security
