linux-kernel - Re: [RFC v2 03/83] Add super.h.

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]

Date:   Thu, 15 Mar 2018 10:05:00 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Andiry Xu <jix024@....ucsd.edu>
Cc:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        Dan Williams <dan.j.williams@...el.com>,
        "Rudoff, Andy" <andy.rudoff@...el.com>, coughlan@...hat.com,
        Steven Swanson <swanson@...ucsd.edu>,
        Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.com>,
        swhiteho@...hat.com, miklos@...redi.hu,
        Jian Xu <andiry.xu@...il.com>, Andiry Xu <jix024@...ucsd.edu>
Subject: Re: [RFC v2 03/83] Add super.h.

On Thu, Mar 15, 2018 at 7:11 AM, Andiry Xu <jix024@....ucsd.edu> wrote:
> On Wed, Mar 14, 2018 at 9:54 PM, Darrick J. Wong
> <darrick.wong@...cle.com> wrote:
>> On Sat, Mar 10, 2018 at 10:17:44AM -0800, Andiry Xu wrote:

>>> +     /* s_mtime and s_wtime should be together and their order should not be
>>> +      * changed. we use an 8 byte write to update both of them atomically
>>> +      */
>>> +     __le32          s_mtime;                /* mount time */
>>> +     __le32          s_wtime;                /* write time */
>>
>> Hmmm, 32-bit timestamps?  2038 isn't that far away...
>>
>
> I will try fixing this in the next version.

I would also recommend adding nanosecond-resolution timestamps.
In theory, a signed 64-bit nanosecond field is sufficient for each timestamp
(it's good for several hundred years), but the more common format uses
64-bit seconds and 32-bit nanoseconds in other file systems.

Unfortunately it looks, you will have to come up with a more sophisticated
update method above, even if you leave out the nanoseconds, you can't
easily rely on a 16-byte atomic update across architectures to deal with
the two 64-bit timestamps. For the superblock fields, you might be able
to get away with using second resolution, and then encoding the
timestamps as a signed 64-bit 'mkfs time' along with two unsigned
32-bit times added on top, which gives you a range of 136 years mount
a file system after its creation.

      Arnd