linux-kernel - Re: [PATCH 2/3] [v2] m68k: mac: use time64

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]

Message-ID: <alpine.LNX.2.21.1807182333150.41@nippy.intranet>
Date:   Wed, 18 Jul 2018 23:49:20 +1000 (AEST)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Arnd Bergmann <arnd@...db.de>
cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Joshua Thompson <funaho@...ai.org>,
        Mathieu Malaterre <malat@...ian.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Greg Ungerer <gerg@...ux-m68k.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Meelis Roos <mroos@...ux.ee>,
        Andreas Schwab <schwab@...ux-m68k.org>
Subject: Re: [PATCH 2/3] [v2] m68k: mac: use time64_t in RTC handling

On Wed, 18 Jul 2018, Arnd Bergmann wrote:

> Hmm, apparently I forgot to update via_read_time(), that one
> is indeed bogus and now inconsistent with the other functions.
> 
> The change in via_write_time() seems at least consistent wtih what we do 
> elsewhere, and using __u32 makes this code more portable. (yes, I 
> realize that 64-bit powermac doesn't use the VIA RTC, but it feels 
> better to write code portably anyway).
> 

As for portability, I think you just contradicted yourself. But I take 
your point about consistency. So I won't object to adopting __u32.

> I'd suggest we do it like below to make it consistent with the
> rest again, using the 1904..2040 range of dates and no warning
> for invalid dates.
> 
> If you agree, I'll send that as a proper patch.
> 

Geert may instead wish to fixup or revert the patch he has committed 
already...

>        Arnd
> 
> diff --git a/arch/m68k/mac/misc.c b/arch/m68k/mac/misc.c
> index bf8df47a6d09..8335509969f1 100644
> --- a/arch/m68k/mac/misc.c
> +++ b/arch/m68k/mac/misc.c
> @@ -255,12 +255,13 @@ static void via_write_pram(int offset, __u8 data)
>   * is basically any machine with Mac II-style ADB.
>   */
> 
> -static long via_read_time(void)
> +static time64_t via_read_time(void)
>  {
>         union {
>                 __u8 cdata[4];
> -               long idata;
> +               __u32 idata;
>         } result, last_result;
> +       time64_t ret;

ret isn't used.

>         int count = 1;
> 
>         via_pram_command(0x81, &last_result.cdata[3]);
> @@ -279,12 +280,8 @@ static long via_read_time(void)
>                 via_pram_command(0x89, &result.cdata[1]);
>                 via_pram_command(0x8D, &result.cdata[0]);
> 
> -               if (result.idata == last_result.idata) {
> -                       if (result.idata < RTC_OFFSET)
> -                               result.idata += 0x100000000ull;
> -
> -                       return result.idata - RTC_OFFSET;
> -               }
> +               if (result.idata == last_result.idata)
> +                       return (time64_t(result.idata) - RTC_OFFSET);
> 

Did you mean to write,

			return (time64_t)result.idata - RTC_OFFSET;

?

--