On Tue, Jul 09, 2024 at 02:58:06PM +0200, Arnd Bergmann wrote: > On Tue, Jul 9, 2024, at 14:42, Jiri Olsa wrote: > > 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 > > If this cannot be used on any other architectures, I would > suggest adding it to the architecture specific list instead, > probably number #335, which is unused on x86-64. > > I was under the assumption that this would theoretically be > useful for non-x86 architectures in the future, in which yes, at the moment uretprobe is implemented on x86_64 only, but it could be perhaps implemented on other archs in future > case you should reserve the same syscall number everywhere hum, is that necessary? I don't mind, but I don't see why it should be the same number on another archs? > now and rely the stub in kernel/sys_ni.c for those that are > missing the implementation. thanks, jirka
