Re: [PATCH 1/3] hfs: stop using timespec based interfaces

[Arnd Bergmann]

On Wed, Jun 20, 2018 at 6:55 PM, Viacheslav Dubeyko <slava@xxxxxxxxxxx> wrote:
> On Tue, 2018-06-19 at 21:42 +0200, Arnd Bergmann wrote:
>> On Tue, Jun 19, 2018 at 7:03 PM, Viacheslav Dubeyko <slava@xxxxxxxxxxx> wrote:

>> We never followed that interpretation in Linux though. As I wrote,
>> on 64-bit machines, these two calculations (hfs and hfs+,
>> respectively)
>>
>> #define __hfs_m_to_utime(sec)   (be32_to_cpu(sec) - 2082844800U  +
>> sys_tz.tz_minuteswest * 60)
>> #define __hfsp_mt2ut(t)                (be32_to_cpu(t) - 2082844800U)
>>
>> just wrap around when reading the timestamps before 1970 from
>> disk. On 32-bit machines they get wrapped another time when
>> we assign them to a signed 32-bit time_t.
>>
>
> The whole patchset looks reasonable for me. I simply guess what the
> correct behaviour of HFS/HFS+ file system driver could look like for
> the case of achieving 2040 year. So, maybe the good way could be to
> mount in the READ-ONLY mode. What do you think?

We've discussed doing that in VFS before, this is something we
need to revisit, but I'd like to do it in common code rather than
in every file system with a particular limit.

Deepa has a patch set to introduce minimum/maximum timestamps
in the superblock for this. We definitely want to use that for limiting
the range of utimensat() arguments from user space, and the idea
we had discussed in the past was to have a way to enforce
read-only mounting of file systems that cannot write current i_mtime
values past a certain (user-defined) future date.

We actually need something like that soon, as there are some
organizations that want to support super-long service lifetimes
for Linux systems (e.g. cars, industrial machines, ...) and want
an early-fail behavior to ensure that everything that works today
can in principle keep working for the foreseeable future, while
everything that is known to break can be forced to break already.

This is clearly not a priority for HFS in particular, but there is no
reason for HFS to be different from ext3 here, which has a similar
problem (timestamps are defined to range from 1902 to 2038).

>>  /* time macros: convert between 1904-2040 and 1970-2106 range,
>>   * pre-1970 timestamps are interpreted as post-2038 times after
>> wrap-around */
>> -#define __hfsp_mt2ut(t)                (be32_to_cpu(t) -
>> 2082844800U)
>> +#define __hfsp_mt2ut(t)                ((time64_t)be32_to_cpu(t) -
>> 2082844800U)
>>  #define __hfsp_ut2mt(t)                (cpu_to_be32(t +
>> 2082844800U))
>>
>>  /* compatibility */
>>
>> I can submit that separately so that it can get backported into
>> stable kernels if you like, with the type changes as a follow-up
>> on top.
>>
>
> Sounds good.

Ok, I'll send an updated version with that patch first then.

       Arnd