Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
In-Reply-To: <20180623060052.ufrlbybeys2xxt5l@eaf>
References: <20180622141758.229589-1-arnd@arndb.de> <20180623060052.ufrlbybeys2xxt5l@eaf>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Tue, 10 Jul 2018 17:26:07 +0200
Message-ID: <CAK8P3a0Ag-rZmDO0H6Yvp6++=0Mr4ObLM+Y3f-n6jUvzbZsyUg@mail.gmail.com>
Subject: Re: [PATCH] hfs/hfsplus: use documented official timestamp range
To:     =?UTF-8?Q?Ernesto_A=2E_Fern=C3=A1ndez?= 
        <ernesto.mnd.fernandez@gmail.com>
Cc:     Vyacheslav Dubeyko <slava@dubeyko.com>,
        y2038 Mailman List <y2038@lists.linaro.org>,
        "# 3.4.x" <stable@vger.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Sat, Jun 23, 2018 at 8:00 AM, Ernesto A. Fern=C3=A1ndez
<ernesto.mnd.fernandez@gmail.com> wrote:
> On Fri, Jun 22, 2018 at 04:17:32PM +0200, Arnd Bergmann wrote:
>> According to the official documentation for HFS+ [1], inode timestamps
>> are supposed to cover the time range from 1904 to 2040 as originally
>> used in classic MacOS.
>>
>> The traditional Linux usage is to convert the timestamps into an unsigne=
d
>> 32-bit number based on the Unix epoch and from there to a time_t. On
>> 32-bit systems, that wraps the time from 2038 to 1902, so the last
>> two years of the valid time range become garbled. On 64-bit systems,
>> all times before 1970 get turned into timestamps between 2038 and 2106,
>> which is more convenient but also different from the documented behavior=
.
>>
>> The same behavior is used in Darwin and presumaby all versions of MacOS =
X,
>> as seen in the to_hfs_time() function in [2]. It is unclear whether this
>> is a bug in the file system code, or intentional but undocumented behavi=
or.
>
> But the to_bsd_time() function considers wrapped timestamps as invalid,
> doesn't it? So it seems they simply don't care about the post-2040 (or
> pre-1970) case?

Sorry for the late reply. Just got back to looking at what remains for the
file systems.

You are of course right, my mistake: Apple writes a wrapped date when
converting from bsd time to on-disk format, but does treat the wrapped
dates as invalid when reading
>> diff --git a/fs/hfsplus/hfsplus_fs.h b/fs/hfsplus/hfsplus_fs.h
>> index d9255abafb81..57838ef4dcdc 100644
>> --- a/fs/hfsplus/hfsplus_fs.h
>> +++ b/fs/hfsplus/hfsplus_fs.h
>> @@ -530,8 +530,9 @@ int hfsplus_submit_bio(struct super_block *sb, secto=
r_t sector, void *buf,
>>                      void **data, int op, int op_flags);
>>  int hfsplus_read_wrapper(struct super_block *sb);
>>
>> -/* time macros */
>> -#define __hfsp_mt2ut(t)              (be32_to_cpu(t) - 2082844800U)
>> +/* time macros: convert between 1904-2040 and 1970-2106 range,
>> + * pre-1970 timestamps are interpreted as post-2038 times after wrap-ar=
ound */
>
> This comment seems to be from the original series, maybe you forgot to
> change it?

Correct. I'll change it and resend it with a fixed changelog.

      Arnd