netdev - Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

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:   Tue, 20 Jun 2017 22:15:36 +0100
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Benjamin Gaignard <benjamin.gaignard@...aro.org>
Cc:     Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
        Baruch Siach <baruch@...s.co.il>,
        "patches@...nsource.wolfsonmicro.com" 
        <patches@...nsource.wolfsonmicro.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Pavel Machek <pavel@....cz>,
        Thomas Gleixner <tglx@...utronix.de>,
        "x86@...nel.org" <x86@...nel.org>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Chen-Yu Tsai <wens@...e.org>, Ingo Molnar <mingo@...hat.com>,
        Sylvain Lemieux <slemieux.tyco@...il.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Len Brown <len.brown@...el.com>,
        "linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
        Jason Cooper <jason@...edaemon.net>,
        "rtc-linux@...glegroups.com" <rtc-linux@...glegroups.com>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        Hans Ulli Kroll <ulli.kroll@...glemail.com>,
        "adi-buildroot-devel@...ts.sourceforge.net" 
        <adi-buildroot-devel@...ts.sourceforge.net>,
        Vladimir Zapolskiy <vz@...ia.com>,
        John Stultz <john.stultz@...aro.org>,
        Gregory Clement <gregory.clement@...e-electrons.com>,
        Michael Chan <michael.chan@...adcom.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Barry Song <baohua@...nel.org>,
        Support Opensource <Support.Opensource@...semi.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Steve Twiss <stwiss.opensource@...semi.com>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>
Subject: Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote:
> 2017-06-20 15:48 GMT+02:00 Alexandre Belloni
> <alexandre.belloni@...e-electrons.com>:
> >> Yes, that's argument against changing rtc _drivers_ for hardware that
> >> can not do better than 32bit. For generic code (such as 44/51 sysfs,
> >> 51/51 suspend test), the change still makes sense.
> 
> What I had in mind when writing those patches was to remove the limitations
> coming from those functions usage, even more since they been marked has
> deprecated.

I'd say that they should not be marked as deprecated.  They're entirely
appropriate for use with hardware that only supports a 32-bit
representation of time.

It's entirely reasonable to fix the ones that use other representations
that exceed that, but for those which do not, we need to keep using the
32-bit versions.  Doing so actually gives us _more_ flexibility in the
future.

Consider that at the moment, we define the 32-bit RTC representation to
start at a well known epoch.  We _could_ decide that when it wraps to
0x80000000 seconds, we'll define the lower 0x40000000 seconds to mean
dates in the future - and keep rolling that forward each time we cross
another 0x40000000 seconds.  Unless someone invents a real time machine,
we shouldn't need to set a modern RTC back to 1970.

If we convert the 32-bit counter RTC drivers to use 64-bit conversions,
then we're completely stuffed, because the lower 32-bits will always
be relative to the epoch, and we can't change that without breaking
the 64-bit users.

So, keep the 32-bit conversion functions, do not deprecate them, and
think about the future possibilities.

I really think this "get rid of 32-bit time representations" is a much
to narrow focus on the wrong problem.  You can't ever fix 32-bit time
representations by just adding additional zeros into the MSB bits.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.