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: <Zo0wG8e7BwudENQI@krava>
Date: Tue, 9 Jul 2024 14:42:03 +0200
From: Jiri Olsa <olsajiri@...il.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Jiri Olsa <olsajiri@...il.com>, 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 09, 2024 at 02:20:26PM +0200, Arnd Bergmann wrote:
> 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.

hum, so it's hooked in:
  190fec72df4a uprobe: Wire up uretprobe system call

and the intention is to have it ONLY for x86_64 (as stated above),
if that's not what happened I need to fix it, please let me know
what's the problem

thanks,
jirka