linux-ext4 - Re: [PATCH 3/6] ext4: use ktime_get_real_seconds for i

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, 21 Jun 2018 22:07:47 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Andreas Dilger <adilger@...ger.ca>
Cc:     "Theodore Ts'o" <tytso@....edu>, Jan Kara <jack@...e.com>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        Jan Kara <jack@...e.cz>, Tahsin Erdogan <tahsin@...gle.com>,
        Miao Xie <miaoxie@...wei.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/6] ext4: use ktime_get_real_seconds for i_dtime

On Thu, Jun 21, 2018 at 7:27 PM, Andreas Dilger <adilger@...ger.ca> wrote:
> On Jun 20, 2018, at 9:33 AM, Arnd Bergmann <arnd@...db.de> wrote:
>>
>> We only care about the low 32-bit for i_dtime as explained in commit
>> b5f515735bea ("ext4: avoid Y2038 overflow in recently_deleted()"), so
>> the use of get_seconds() is correct here, but that function is getting
>> removed in the process of the y2038 fixes, so let's use the modern
>> ktime_get_real_seconds() here.
>>
>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>
> Looks OK, one minor cleanup possible.
>
> Reviewed-by: Andreas Dilger <adilger@...ger.ca>
>>       ext4_orphan_del(handle, inode);
>> -     EXT4_I(inode)->i_dtime  = get_seconds();
>> +     EXT4_I(inode)->i_dtime  = ktime_get_real_seconds();
>
> Not strictly necessary, but it might be good from a code clarity POV
> to use:
>
>         EXT4_I(inode)->i_dtime  = (__u32)ktime_get_real_seconds();
>
> so that it is more clear we are aware that this is being truncated
> to a 32-bit value.

Right, I've been a bit inconsistent here across file systems, I've
done this in some other ones, using either a cast or a lower_32_bits()
function call. Changed it as you suggested here now.

     Arnd