linux-kernel - Re: [PATCH] csky: Improve abiv1 mem ops performance with glibc codes

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] [day] [month] [year] [list]

Date:   Mon, 1 Jul 2019 17:46:09 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Guo Ren <guoren@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        linux-csky@...r.kernel.org, Guo Ren <ren_guo@...ky.com>
Subject: Re: [PATCH] csky: Improve abiv1 mem ops performance with glibc codes

On Mon, Jul 1, 2019 at 5:26 PM Guo Ren <guoren@...nel.org> wrote:
> On Mon, Jul 1, 2019 at 10:52 PM Arnd Bergmann <arnd@...db.de> wrote:
> >
> > On Sat, Jun 29, 2019 at 7:36 AM <guoren@...nel.org> wrote:
> > >
> > > From: Guo Ren <ren_guo@...ky.com>
> > >
> > > These codes are copied from glibc/string directory, they are the generic
> > > implementation for string operations. We may further optimize them with
> > > assembly code in the future.
> > >
> > > In fact these code isn't tested enough for kernel, but we've tested them
> > > on glibc and it seems good. We just trust them :)
> >
> > Are these files from the architecture independent portion of glibc or
> > are they csky specific? If they are architecture independent, we might
> > want to see if they make sense for other architectures as well, and
> > add them to lib/ rather than arch/csky/lib/
> They are just copied from glibc-2.28/string/*.c and they are generic.
> OK, I'll try to add them to lib/.

Ok. Note that lib/string.c contains very basic versions of these already,
so please see which of the functions you have actually make a
difference in practice over those (if you haven't done that already).

Otherwise you can probably follow the example of the libgcc functions
in lib/ashldi3.c etc: add a Kconfig symbol like CONFIG_GENERIC_LIB_ASHLDI3
for each function you had, put the glibc version into a new file, and allow
architectures to select them individually, which in turn should
replace the version from lib/string.c.

       Arnd