linux-kernel - Re: [PATCH 5.9 24/74] x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 3 Nov 2020 07:35:29 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Hans-Peter Jansen <hpj@...la.net>
Cc:     linux-kernel@...r.kernel.org,
        Dan Williams <dan.j.williams@...el.com>,
        stable@...r.kernel.org, Borislav Petkov <bp@...e.de>,
        Tony Luck <tony.luck@...el.com>,
        Michael Ellerman <mpe@...erman.id.au>
Subject: Re: [PATCH 5.9 24/74] x86, powerpc: Rename memcpy_mcsafe() to
 copy_mc_to_{user, kernel}()

On Mon, Nov 02, 2020 at 10:34:08PM +0100, Hans-Peter Jansen wrote:
> Hi Greg, hi Dan,
> 
> Am Samstag, 31. Oktober 2020, 12:36:06 CET schrieb Greg Kroah-Hartman:
> > From: Dan Williams <dan.j.williams@...el.com>
> > 
> > commit ec6347bb43395cb92126788a1a5b25302543f815 upstream.
> > 
> > In reaction to a proposal to introduce a memcpy_mcsafe_fast()
> > implementation Linus points out that memcpy_mcsafe() is poorly named
> > relative to communicating the scope of the interface. Specifically what
> > addresses are valid to pass as source, destination, and what faults /
> > exceptions are handled.
> > 
> > 
> > Introduce an x86 copy_mc_fragile() name as the rename for the
> > low-level x86 implementation formerly named memcpy_mcsafe(). It is used
> > as the slow / careful backend that is supplanted by a fast
> > copy_mc_generic() in a follow-on patch.
> > 
> > One side-effect of this reorganization is that separating copy_mc_64.S
> > to its own file means that perf no longer needs to track dependencies
> > for its memcpy_64.S benchmarks.
> > 
> > ---
> > arch/powerpc/lib/copy_mc_64.S                          |  242 +++++++++++++++++
> > arch/powerpc/lib/memcpy_mcsafe_64.S                    |  242 -----------------
> 
> > tools/testing/selftests/powerpc/copyloops/copy_mc_64.S |  242 +++++++++++++++++ 
> 
> This change leaves a dangling symlink in 
> tools/testing/selftests/powerpc/copyloops behind. At least, this is, what I 
> could track down, when building 5.9.3 within an environment, that bails out 
> on this:
> 
> [ 2908s] calling /usr/lib/rpm/brp-suse.d/brp-25-symlink
> [ 2908s] ERROR: link target doesn't exist (neither in build root nor in installed system):
> [ 2908s]   /usr/src/linux-5.9.3-lp152.3-vanilla/tools/testing/selftests/powerpc/copyloops/memcpy_mcsafe_64.S -> /usr/src/linux-5.9.3-lp152.3-vanilla/arch/powerpc/lib/memcpy_mcsafe_64.S
> [ 2908s] Add the package providing the target to BuildRequires and Requires
> [ 2909s] INFO: relinking /usr/src/linux-5.9.3-lp152.3-vanilla/tools/testing/selftests/powerpc/primitives/asm/asm-compat.h -> ../../../../../../arch/powerpc/include/asm/asm-compat.h (was ../.././../../../../arch/powerpc/include/asm/asm-compat.h)
> 
> Linus` tree seems to not suffer from this, though.

Ah, that kind of makes sense, I saw odd things with these patches that I
couldn't figure out.

So, is there a symlink that I need to add/fix to resolve this?

thanks,

greg k-h