linux-kernel - Re: [PATCH v2 0/6] Delete timespec64

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABeXuvrvATrw9QfVpi1s80Duen6jf5sw+pU91yN_0f3N1xWJQQ@mail.gmail.com>
Date:   Sat, 7 Dec 2019 18:04:38 -0800
From:   Deepa Dinamani <deepa.kernel@...il.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        ceph-devel <ceph-devel@...r.kernel.org>,
        OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
        Jeff Layton <jlayton@...nel.org>,
        CIFS <linux-cifs@...r.kernel.org>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        Richard Weinberger <richard@....at>,
        Steve French <stfrench@...rosoft.com>
Subject: Re: [PATCH v2 0/6] Delete timespec64_trunc()

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