linux-kernel - Re: "beyond 2038" warnings from loopback mount is noisy

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: <20190903223815.GH2899@mit.edu>
Date:   Tue, 3 Sep 2019 18:38:15 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Deepa Dinamani <deepa.kernel@...il.com>, Qian Cai <cai@....pw>,
        Jeff Layton <jlayton@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Andreas Dilger <adilger.kernel@...ger.ca>
Subject: Re: "beyond 2038" warnings from loopback mount is noisy

On Tue, Sep 03, 2019 at 11:48:14PM +0200, Arnd Bergmann wrote:
> I think the warning as it was intended makes sense, the idea
> was never to warn on every inode update for file systems that
> cannot handle future dates, only to warn when we
> 
> a) try to set a future date
> b) fail to do that because the space cannot be made available.

What do you mean by "try to set a future date"?  Do you mean a trying
to set a date after 2038 (when it can no longer fit in a signed 32-bit
value)?  Because that's not what the commit is currently doing.....

> I would prefer to fix it on top of the patches I already merged.
> 
> Maybe something like:
> 
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 9e3ae3be3de9..5a971d1b6d5e 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -835,7 +835,9 @@ do {
>                                  \
>                 }
>          \
>         else    {\
>                 (raw_inode)->xtime = cpu_to_le32(clamp_t(int32_t,
> (inode)->xtime.tv_sec, S32_MIN, S32_MAX));    \
> -               ext4_warning_inode(inode, "inode does not support
> timestamps beyond 2038"); \
> +               if (((inode)->xtime.tv_sec != (raw_inode)->xtime) &&     \
> +                   ((inode)->i_sb->s_time_max > S32_MAX))
>          \
> +                       ext4_warning_inode(inode, "inode does not
> support timestamps beyond 2038"); \
>         } \
>  } while (0)

Sure, that's much less objectionable.

> However, I did expect that people might have legacy ext3 file system
> images that they mount, and printing a warning for each write would
> also be wrong for those.

I guess I'm much less convinced that 10-15 years from now, there will
be many legacy ext3 file systems left.  Storage media doesn't last
that long, and if file systems get moved around, e2fsck will be run at
least once, and so adding some e2fsck-time warnings seems to be a
better approach IMHO.

						- Ted