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: <27d1943a0027cb4f658334fad8dc880df133c22d.camel@kernel.org>
Date:   Tue, 20 Aug 2019 07:05:10 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Deepa Dinamani <deepa.kernel@...il.com>, viro@...iv.linux.org.uk,
        linux-kernel@...r.kernel.org
Cc:     linux-fsdevel@...r.kernel.org, y2038@...ts.linaro.org,
        arnd@...db.de, adilger.kernel@...ger.ca, adrian.hunter@...el.com,
        aivazian.tigran@...il.com, al@...rsen.net,
        anna.schumaker@...app.com, anton@...msg.org,
        asmadeus@...ewreck.org, ccross@...roid.com,
        ceph-devel@...r.kernel.org, coda@...cmu.edu,
        codalist@...a.cs.cmu.edu, darrick.wong@...cle.com,
        dedekind1@...il.com, devel@...ts.orangefs.org, dsterba@...e.com,
        dushistov@...l.ru, dwmw2@...radead.org, ericvh@...il.com,
        gregkh@...uxfoundation.org, hch@...radead.org, hch@....de,
        hirofumi@...l.parknet.co.jp, hubcap@...ibond.com,
        idryomov@...il.com, jack@...e.com, jaegeuk@...nel.org,
        jaharkes@...cmu.edu, jfs-discussion@...ts.sourceforge.net,
        jlbec@...lplan.org, keescook@...omium.org,
        linux-cifs@...r.kernel.org, linux-ext4@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net,
        linux-karma-devel@...ts.sourceforge.net,
        linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org,
        linux-ntfs-dev@...ts.sourceforge.net, linux-xfs@...r.kernel.org,
        lucho@...kov.net, luisbg@...nel.org, martin@...ibond.com,
        me@...copeland.com, mikulas@...ax.karlin.mff.cuni.cz,
        nico@...xnic.net, phillip@...ashfs.org.uk,
        reiserfs-devel@...r.kernel.org, richard@....at, sage@...hat.com,
        salah.triki@...il.com, sfrench@...ba.org, shaggy@...nel.org,
        tj@...nel.org, tony.luck@...el.com,
        trond.myklebust@...merspace.com, tytso@....edu,
        v9fs-developer@...ts.sourceforge.net, yuchao0@...wei.com,
        zyan@...hat.com
Subject: Re: [PATCH v8 00/20] vfs: Add support for timestamp limits

On Sun, 2019-08-18 at 09:57 -0700, Deepa Dinamani wrote:
> The series is an update and a more complete version of the
> previously posted series at
> https://lore.kernel.org/linux-fsdevel/20180122020426.2988-1-deepa.kernel@gmail.com/
> 
> Thanks to Arnd Bergmann for doing a few preliminary reviews.
> They helped me fix a few issues I had overlooked.
> 
> The limits (sometimes granularity also) for the filesystems updated here are according to the
> following table:
> 
> File system   Time type                      Start year Expiration year Granularity
> cramfs        fixed                          0          0
> romfs         fixed                          0          0
> pstore        ascii seconds (27 digit ascii) S64_MIN    S64_MAX         1
> coda          INT64                          S64_MIN    S64_MAX         1
> omfs          64-bit milliseconds            0          U64_MAX/ 1000   NSEC_PER_MSEC
> befs          unsigned 48-bit seconds        0          0xffffffffffff  alloc_super
> bfs           unsigned 32-bit seconds        0          U32_MAX         alloc_super
> efs           unsigned 32-bit seconds        0          U32_MAX         alloc_super
> ext2          signed 32-bit seconds          S32_MIN    S32_MAX         alloc_super
> ext3          signed 32-bit seconds          S32_MIN    S32_MAX         alloc_super
> ext4 (old)    signed 32-bit seconds          S32_MIN    S32_MAX         alloc_super
> ext4 (extra)  34-bit seconds, 30-bit ns      S32_MIN    0x37fffffff	1
> freevxfs      u32 secs/usecs                 0          U32_MAX         alloc_super
> jffs2         unsigned 32-bit seconds        0          U32_MAX         alloc_super
> jfs           unsigned 32-bit seconds/ns     0          U32_MAX         1
> minix         unsigned 32-bit seconds        0          U32_MAX         alloc_super
> orangefs      u64 seconds                    0          U64_MAX         alloc_super
> qnx4          unsigned 32-bit seconds        0          U32_MAX         alloc_super
> qnx6          unsigned 32-bit seconds        0          U32_MAX         alloc_super
> reiserfs      unsigned 32-bit seconds        0          U32_MAX         alloc_super
> squashfs      unsigned 32-bit seconds        0          U32_MAX         alloc_super
> ufs1          signed 32-bit seconds          S32_MIN    S32_MAX         NSEC_PER_SEC
> ufs2          signed 64-bit seconds/u32 ns   S64_MIN    S64_MAX         1
> xfs           signed 32-bit seconds/ns       S32_MIN    S32_MAX         1
> ceph          unsigned 32-bit second/ns      0          U32_MAX         1000

Looks reasonable, overall.

Note that the granularity changed recently for cephfs. See commit
0f7cf80ae96c2a (ceph: initialize superblock s_time_gran to 1).

In any case, you can add my Acked-by

-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ