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

[Arnd Bergmann]

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
case you should reserve the same syscall number everywhere
now and rely the stub in kernel/sys_ni.c for those that are
missing the implementation.

     Arnd