linux-kernel - Re: [PATCH v2] m68k: use kernel's generic muldi3 libgcc function

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]

Message-Id: <992c4d62-380d-4908-a688-77197d9c4cbd@app.fastmail.com>
Date: Mon, 02 Dec 2024 10:27:48 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Greg Ungerer" <gerg@...ux-m68k.org>,
 "Geert Uytterhoeven" <geert@...ux-m68k.org>
Cc: linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] m68k: use kernel's generic muldi3 libgcc function

On Mon, Dec 2, 2024, at 02:34, Greg Ungerer wrote:
> Arnd, ping...

Sorry I hadn't realized you were waiting for me.

> On 6/11/24 08:04, Greg Ungerer wrote:
>> On 5/11/24 21:46, Geert Uytterhoeven wrote:
>>> On Mon, Nov 13, 2023 at 2:32 PM Greg Ungerer <gerg@...ux-m68k.org> wrote:
>>>> Use the kernels own generic lib/muldi3.c implementation of muldi3 for
>>>> 68K machines. Some 68K CPUs support 64bit multiplies so move the arch
>>>> specific umul_ppmm() macro into a header file that is included by
>>>> lib/muldi3.c. That way it can take advantage of the single instruction
>>>> when available.
>>>>
>>>> There does not appear to be any existing mechanism for the generic
>>>> lib/muldi3.c code to pick up an external arch definition of umul_ppmm().
>>>> Create an arch specific libgcc.h that can optionally be included by
>>>> the system include/linux/libgcc.h to allow for this.
>>>>
>>>> Somewhat oddly there is also a similar definition of umul_ppmm() in
>>>> the non-architecture code in lib/crypto/mpi/longlong.h for a wide range
>>>> or machines. Its presence ends up complicating the include setup and
>>>> means not being able to use something like compiler.h instead. Actually
>>>> there is a few other defines of umul_ppmm() macros spread around in
>>>> various architectures, but not directly usable for the m68k case.
>>>>
>>>> Signed-off-by: Greg Ungerer <gerg@...ux-m68k.org>
>>>
>>> Reviewed-by: Geert Uytterhoeven <geert@...ux-m68k.org>
>>>
>>>>   arch/Kconfig                   |  8 +++
>>>>   arch/m68k/Kconfig              |  2 +
>>>>   arch/m68k/include/asm/libgcc.h | 20 +++++++
>>>>   arch/m68k/lib/Makefile         |  2 +-
>>>>   arch/m68k/lib/muldi3.c         | 97 ----------------------------------
>>>>   include/linux/libgcc.h         |  4 ++
>>>>   6 files changed, 35 insertions(+), 98 deletions(-)
>>>>   create mode 100644 arch/m68k/include/asm/libgcc.h
>>>>   delete mode 100644 arch/m68k/lib/muldi3.c
>>>
>>> I had this in my local tree for about a year.
>>> Is it fine to queue this in the m68k tree, or does this need a broader
>>> coverage?
>> 
>> I am still in favor of it :-)
>> Would be good to get some feedback on the common code changes, like the change
>> to libgcc.h.

Reviewed-by: Arnd Bergmann <arnd@...db.de>

This looks fine to me, nice cleanup. My instinct at first was
to add an asm-generic/libgcc.h as a fallback in place of
the Kconfig symbol and move the common macro there, but there
really isn't much benefit to that over your version. Either way,
please merge this through the m68k tree.

      Arnd