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

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

Hi all,

Today's linux-next merge of the fs-next tree got conflicts in:

  arch/arm64/include/asm/unistd.h
  arch/arm64/include/asm/unistd32.h

between commit:

  ea0130bf3c45 ("arm64: convert unistd_32.h to syscall.tbl format")

from the asm-generic tree and commit:

  e6873349f700 ("fs/xattr: add *at family syscalls")

from the vfs-brauner tree.

I fixed it up (I used the former versions) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

Hi all,

On Tue, 9 Jul 2024 10:57:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the fs-next tree got conflicts in:
> 
>   arch/arm64/include/asm/unistd.h
>   arch/arm64/include/asm/unistd32.h
> 
> between commit:
> 
>   ea0130bf3c45 ("arm64: convert unistd_32.h to syscall.tbl format")
> 
> from the asm-generic tree and commit:
> 
>   e6873349f700 ("fs/xattr: add *at family syscalls")
> 
> from the vfs-brauner tree.
> 
> I fixed it up (I used the former versions) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

This resolution may be not enough as I now get the following warnings
from the arm64 defconfig build:

<stdin>:1603:2: warning: #warning syscall setxattrat not implemented [-Wcpp]
<stdin>:1606:2: warning: #warning syscall getxattrat not implemented [-Wcpp]
<stdin>:1609:2: warning: #warning syscall listxattrat not implemented [-Wcpp]
<stdin>:1612:2: warning: #warning syscall removexattrat not implemented [-Wcpp]

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Arnd Bergmann]

On Tue, Jul 9, 2024, at 12:08, Stephen Rothwell wrote:
> On Tue, 9 Jul 2024 10:57:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the fs-next tree got conflicts in:
>> 
>>   arch/arm64/include/asm/unistd.h
>>   arch/arm64/include/asm/unistd32.h
>> 
>> between commit:
>> 
>>   ea0130bf3c45 ("arm64: convert unistd_32.h to syscall.tbl format")
>> 
>> from the asm-generic tree and commit:
>> 
>>   e6873349f700 ("fs/xattr: add *at family syscalls")
>> 
>> from the vfs-brauner tree.
>> 
>> I fixed it up (I used the former versions) and can carry the fix as
>> necessary. This is now fixed as far as linux-next is concerned, but any
>> non trivial conflicts should be mentioned to your upstream maintainer
>> when your tree is submitted for merging.  You may also want to consider
>> cooperating with the maintainer of the conflicting tree to minimise any
>> particularly complex conflicts.
>
> This resolution may be not enough as I now get the following warnings
> from the arm64 defconfig build:
>
> <stdin>:1603:2: warning: #warning syscall setxattrat not implemented [-Wcpp]
> <stdin>:1606:2: warning: #warning syscall getxattrat not implemented [-Wcpp]
> <stdin>:1609:2: warning: #warning syscall listxattrat not implemented [-Wcpp]
> <stdin>:1612:2: warning: #warning syscall removexattrat not implemented [-Wcpp]

I see. The newly added syscalls need to be copied from
include/uapi/asm-generic/unistd.h into the newly added
scripts/syscall.tbl. I am aware of this and was planning
to send this as a fixup afterward to avoid an awkward
four-way merge with the uretprobe and xattrat patches.

Based on your merge in 1dd7a574e54e ("Merge branch
'for-next' of git://git.kernel.org/pub/scm/linux/kernel/
git/trace/linux-trace.git"), I think we want this
to be in all syscall.tbl files:

diff --git a/scripts/syscall.tbl b/scripts/syscall.tbl
index b0ea892de12e..4873fa3ca496 100644
--- a/scripts/syscall.tbl
+++ b/scripts/syscall.tbl
@@ -419,3 +419,8 @@
 460	common	lsm_set_self_attr		sys_lsm_set_self_attr
 461	common	lsm_list_modules		sys_lsm_list_modules
 462	common	mseal				sys_mseal
+463	common	setxattrat			sys_setxattrat
+464	common	getxattrat			sys_getxattrat
+465	common	listxattrat			sys_listxattrat
+466	common	removexattrat			sys_removexattrat
+467	64	uretprobe			sys_uretprobe

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'.

      Arnd

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

[Jiri Olsa]

On Tue, Jul 09, 2024 at 01:44:34PM +0200, Arnd Bergmann wrote:
> On Tue, Jul 9, 2024, at 12:08, Stephen Rothwell wrote:
> > On Tue, 9 Jul 2024 10:57:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >> Today's linux-next merge of the fs-next tree got conflicts in:
> >> 
> >>   arch/arm64/include/asm/unistd.h
> >>   arch/arm64/include/asm/unistd32.h
> >> 
> >> between commit:
> >> 
> >>   ea0130bf3c45 ("arm64: convert unistd_32.h to syscall.tbl format")
> >> 
> >> from the asm-generic tree and commit:
> >> 
> >>   e6873349f700 ("fs/xattr: add *at family syscalls")
> >> 
> >> from the vfs-brauner tree.
> >> 
> >> I fixed it up (I used the former versions) and can carry the fix as
> >> necessary. This is now fixed as far as linux-next is concerned, but any
> >> non trivial conflicts should be mentioned to your upstream maintainer
> >> when your tree is submitted for merging.  You may also want to consider
> >> cooperating with the maintainer of the conflicting tree to minimise any
> >> particularly complex conflicts.
> >
> > This resolution may be not enough as I now get the following warnings
> > from the arm64 defconfig build:
> >
> > <stdin>:1603:2: warning: #warning syscall setxattrat not implemented [-Wcpp]
> > <stdin>:1606:2: warning: #warning syscall getxattrat not implemented [-Wcpp]
> > <stdin>:1609:2: warning: #warning syscall listxattrat not implemented [-Wcpp]
> > <stdin>:1612:2: warning: #warning syscall removexattrat not implemented [-Wcpp]
> 
> I see. The newly added syscalls need to be copied from
> include/uapi/asm-generic/unistd.h into the newly added
> scripts/syscall.tbl. I am aware of this and was planning
> to send this as a fixup afterward to avoid an awkward
> four-way merge with the uretprobe and xattrat patches.
> 
> Based on your merge in 1dd7a574e54e ("Merge branch
> 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/
> git/trace/linux-trace.git"), I think we want this
> to be in all syscall.tbl files:
> 
> diff --git a/scripts/syscall.tbl b/scripts/syscall.tbl
> index b0ea892de12e..4873fa3ca496 100644
> --- a/scripts/syscall.tbl
> +++ b/scripts/syscall.tbl
> @@ -419,3 +419,8 @@
>  460	common	lsm_set_self_attr		sys_lsm_set_self_attr
>  461	common	lsm_list_modules		sys_lsm_list_modules
>  462	common	mseal				sys_mseal
> +463	common	setxattrat			sys_setxattrat
> +464	common	getxattrat			sys_getxattrat
> +465	common	listxattrat			sys_listxattrat
> +466	common	removexattrat			sys_removexattrat
> +467	64	uretprobe			sys_uretprobe
> 
> 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'.

hi,
uretprobe is defined only for x86_64, not sure what that means
for scripts/syscall.tbl though

jirka

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

[Arnd Bergmann]

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

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

[Jiri Olsa]

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

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

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

[Jiri Olsa]

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

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

[Arnd Bergmann]

On Tue, Jul 9, 2024, at 15:17, Jiri Olsa wrote:
> On Tue, Jul 09, 2024 at 02:58:06PM +0200, Arnd Bergmann wrote:
>> 
>> 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?

All new system calls have the same number across architectures
since number 403 for consistency (except arch/alpha, which
uses 110 more than the others).

Linus did comment the other day that he did not think we
need to actually assign the numbers when the system calls
are unlikely to actually be implemented on most architectures,
but it would be good to at least add a comment in each
syscall.tbl file to say which syscall the number is going
to be used for if it does get assigned.

     Arnd

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3602 bytes --]

Hi all,

On Tue, 09 Jul 2024 13:44:34 +0200 "Arnd Bergmann" <arnd@arndb.de> wrote:
>
> On Tue, Jul 9, 2024, at 12:08, Stephen Rothwell wrote:
> > On Tue, 9 Jul 2024 10:57:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> >>
> >> Today's linux-next merge of the fs-next tree got conflicts in:
> >> 
> >>   arch/arm64/include/asm/unistd.h
> >>   arch/arm64/include/asm/unistd32.h
> >> 
> >> between commit:
> >> 
> >>   ea0130bf3c45 ("arm64: convert unistd_32.h to syscall.tbl format")
> >> 
> >> from the asm-generic tree and commit:
> >> 
> >>   e6873349f700 ("fs/xattr: add *at family syscalls")
> >> 
> >> from the vfs-brauner tree.
> >> 
> >> I fixed it up (I used the former versions) and can carry the fix as
> >> necessary. This is now fixed as far as linux-next is concerned, but any
> >> non trivial conflicts should be mentioned to your upstream maintainer
> >> when your tree is submitted for merging.  You may also want to consider
> >> cooperating with the maintainer of the conflicting tree to minimise any
> >> particularly complex conflicts.  
> >
> > This resolution may be not enough as I now get the following warnings
> > from the arm64 defconfig build:
> >
> > <stdin>:1603:2: warning: #warning syscall setxattrat not implemented [-Wcpp]
> > <stdin>:1606:2: warning: #warning syscall getxattrat not implemented [-Wcpp]
> > <stdin>:1609:2: warning: #warning syscall listxattrat not implemented [-Wcpp]
> > <stdin>:1612:2: warning: #warning syscall removexattrat not implemented [-Wcpp]  
> 
> I see. The newly added syscalls need to be copied from
> include/uapi/asm-generic/unistd.h into the newly added
> scripts/syscall.tbl. I am aware of this and was planning
> to send this as a fixup afterward to avoid an awkward
> four-way merge with the uretprobe and xattrat patches.
> 
> Based on your merge in 1dd7a574e54e ("Merge branch
> 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/
> git/trace/linux-trace.git"), I think we want this
> to be in all syscall.tbl files:
> 
> diff --git a/scripts/syscall.tbl b/scripts/syscall.tbl
> index b0ea892de12e..4873fa3ca496 100644
> --- a/scripts/syscall.tbl
> +++ b/scripts/syscall.tbl
> @@ -419,3 +419,8 @@
>  460	common	lsm_set_self_attr		sys_lsm_set_self_attr
>  461	common	lsm_list_modules		sys_lsm_list_modules
>  462	common	mseal				sys_mseal
> +463	common	setxattrat			sys_setxattrat
> +464	common	getxattrat			sys_getxattrat
> +465	common	listxattrat			sys_listxattrat
> +466	common	removexattrat			sys_removexattrat

I have added this merge fix patch to the merge of the fs-next tree
today (it is needed when the vfs-brauner tree is merged with the
asm-generic tree):

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 10 Jul 2024 12:16:06 +1000
Subject: [PATCH] fixup for "fs/xattr: add *at family syscalls"

interacting with "arm64: convert unistd_32.h to syscall.tbl format"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 scripts/syscall.tbl | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/scripts/syscall.tbl b/scripts/syscall.tbl
index 797e20ea99a2..86b53c7a815b 100644
--- a/scripts/syscall.tbl
+++ b/scripts/syscall.tbl
@@ -402,3 +402,7 @@
 460	common	lsm_set_self_attr		sys_lsm_set_self_attr
 461	common	lsm_list_modules		sys_lsm_list_modules
 462	common	mseal				sys_mseal
+463	common	setxattrat			sys_setxattrat
+464	common	getxattrat			sys_getxattrat
+465	common	listxattrat			sys_listxattrat
+466	common	removexattrat			sys_removexattrat
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]