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: <CAK8P3a25W5rE093QsmC539d+s038Wv9PmV8Xa76LQzDLk3E8Wg@mail.gmail.com>
Date:   Wed, 17 Oct 2018 17:58:46 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Guo Ren <ren_guo@...ky.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        David Miller <davem@...emloft.net>,
        gregkh <gregkh@...uxfoundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Mark Rutland <mark.rutland@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Rob Herring <robh@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>, c-sky_gcc_upstream@...ky.com
Subject: Re: [PATCH V9 00/21] C-SKY(csky) Linux Kernel Port

On Tue, Oct 16, 2018 at 4:58 AM Guo Ren <ren_guo@...ky.com> wrote:
>
> This is the 9th version patchset to add the Linux kernel port for
> C-SKY(csky) based on linux-4.19-rc3.
>
> There are only a few changes between V8 patchset. Hope it could be
> merged into linux-4.20 and I'm very grateful for any help.

I've gone through the entire series once more and saw no show-stoppers.
The last patch looked like it introduced a bug, but with that one dropped,
I'm happy for the architecture to get merged, unless anyone else
has any last-minute concerns. (Alternatively, explain why I'm wrong
and the code works correctly, of course).

I'd appreciate having someone else take another look at the signal
handling code, the atomics, and the DT bindings and provide another
Ack for those.

The remaining open question is about the 32-bit time_t interfaces.
With 4.20, I did not manage to get the required system calls in place
for using 64-bit time_t in a new architecture, so you will at least
start out using 32-bit time_t and likely have to keep supporting
that going forward, unless we decide to break the ABI here later
on .This is something we normally don't do, but we might make
an exception here, under the assumption that there are no
existing users with the ABI. We can debate that once we get there.

       Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ