On Fri, Dec 6, 2019 at 10:02 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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
