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:   Wed, 20 Jun 2018 18:20:44 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Coly Li <colyli@...e.de>
Cc:     Kent Overstreet <kent.overstreet@...il.com>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Jens Axboe <axboe@...nel.dk>, Michael Lyle <mlyle@...e.org>,
        Tang Junhui <tang.junhui@....com.cn>,
        Hannes Reinecke <hare@...e.com>,
        Bart Van Assche <bart.vanassche@....com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        linux-bcache@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] bcache: stop using the deprecated get_seconds()

On Wed, Jun 20, 2018 at 5:51 PM, Coly Li <colyli@...e.de> wrote:
> On 2018/6/20 5:51 PM, Arnd Bergmann wrote:
>> bcache uses get_seconds() to read the current system time and store it in
>> the superblock as well as in uuid_entry structures that are user visible.
>>
>> This changes over from the deprecated function to
>> ktime_get_real_seconds(), which returns a 64-bit timestamp as it
>> should. Unfortunately, the two structures are still limited to 32 bits,
>> so this won't fix any real problems. Let's at least document that
>> properly, in case we get an updated format in the future it can be
>> fixed. Until then, we still have some time, and checking the tools
>> at https://github.com/koverstreet/bcache-tools reveals no access to
>> any of them.
>>
>> Signed-off-by: Arnd Bergmann <arnd@...db.de>
>
> Hi Arnd,
>
> Firstly thanks to your patch, especially the detailed information in
> patch log, it helps me to understand the problem more easier.
>
> From the information, it seems the problem is current 32bit time stamp
> will be overflow in 2106. So it will be 88 years later, which I have to
> say I don't care.
>
> Also for get_seconds() which works well for current code as many other
> places call it, I would like to keep it.

I'm currently in the process of removing all instances of get_seconds()
with patches like this. In many cases, we actually want to use
ktime_get_seconds() to return a monotonic time that is immune
to concurrent setttimeofday() calls, in others the code needs to be
changed to avoid the y2038 overflow. For bcache, we don't
really need either of them, but I'd still want to move over everything
to ktime_get_* based interfaces.

Should I clarify that motivation in the changelog text further?

I can also do a simple replacement of get_seconds() with
ktime_get_real_seconds() throughout bcache instead of
adding the intermediate helper function.

      Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ