linux-kernel - Re: linux-next: manual merge of the vfs-brauner tree with the asm-generic tree

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: <c25a32c6-8ed0-4ef9-a13e-cb16a89edb73@app.fastmail.com>
Date: Tue, 09 Jul 2024 14:20:26 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Jiri Olsa" <olsajiri@...il.com>
Cc: "Stephen Rothwell" <sfr@...b.auug.org.au>,
 "Christian Brauner" <brauner@...nel.org>,
 Christian Göttsche <cgzones@...glemail.com>,
 "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
 linux-next <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the vfs-brauner tree with the asm-generic tree

On Tue, Jul 9, 2024, at 13:53, Jiri Olsa wrote:
> On Tue, Jul 09, 2024 at 01:44:34PM +0200, Arnd Bergmann wrote:
>
>> Though I'm still not sure what uretprobe is only added
>> to half the architectures at the moment. There is a chance
>> we need a different conditional for it than '64'.
>
> uretprobe is defined only for x86_64, not sure what that means
> for scripts/syscall.tbl though

I meant you hooked it up unconditionally for all architectures
using the old method, i.e. arc, arm64, csky, hexagon, loongarch64,
nios2, openrisc, riscv32, riscv64, and xtensa in addition
to x86-64, but not for the other ABIs: alpha, arm32, m68k,
microblaze, mips-o32, mips-n32, mips64, nios2, parisc32, parisc64,
powerpc32, powerpc64, powerpc-spu, s390-31, s390-64, sh,
sparc32, sparc64, x86-32 and x86-x32.

If that is not the list you had intended, do you have a list
of which architectures actually have the required hardware
to hook it up? It would be good to do this correctly from
the start so we don't rely on architecture maintainers assigning
the numbers individually.

     ARnd