linux-next: manual merge of the pidfd tree with the y2038 tree

linux-next: manual merge of the pidfd tree with the y2038 tree

[Stephen Rothwell]

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

Hi all,

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

  arch/x86/entry/syscalls/syscall_32.tbl
  include/uapi/asm-generic/unistd.h

between commit:

  10a9a4dd92e6 ("arch: add split IPC system calls where needed")
  b1788424aa2e ("y2038: add 64-bit time_t syscalls to all 32-bit architectures")

from the y2038 tree and commit:

  3d2991bc7a67 ("signal: add pidfd_send_signal() syscall")

from the pidfd tree.

I fixed it up (see below) 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

diff --cc arch/x86/entry/syscalls/syscall_32.tbl
index b21ddeeb43cb,6804c1e84b36..000000000000
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@@ -396,36 -396,6 +396,37 @@@
  382	i386	pkey_free		sys_pkey_free			__ia32_sys_pkey_free
  383	i386	statx			sys_statx			__ia32_sys_statx
  384	i386	arch_prctl		sys_arch_prctl			__ia32_compat_sys_arch_prctl
 -385	i386	io_pgetevents		sys_io_pgetevents		__ia32_compat_sys_io_pgetevents
 +385	i386	io_pgetevents		sys_io_pgetevents_time32	__ia32_compat_sys_io_pgetevents
  386	i386	rseq			sys_rseq			__ia32_sys_rseq
+ 387	i386	pidfd_send_signal	sys_pidfd_send_signal		__ia32_sys_pidfd_send_signal
 +# room for arch specific syscalls
 +393	i386	semget			sys_semget    			__ia32_sys_semget
 +394	i386	semctl			sys_semctl    			__ia32_compat_sys_semctl
 +395	i386	shmget			sys_shmget    			__ia32_sys_shmget
 +396	i386	shmctl			sys_shmctl    			__ia32_compat_sys_shmctl
 +397	i386	shmat			sys_shmat     			__ia32_compat_sys_shmat
 +398	i386	shmdt			sys_shmdt     			__ia32_sys_shmdt
 +399	i386	msgget			sys_msgget    			__ia32_sys_msgget
 +400	i386	msgsnd			sys_msgsnd    			__ia32_compat_sys_msgsnd
 +401	i386	msgrcv			sys_msgrcv    			__ia32_compat_sys_msgrcv
 +402	i386	msgctl			sys_msgctl    			__ia32_compat_sys_msgctl
 +403	i386	clock_gettime64		sys_clock_gettime		__ia32_sys_clock_gettime
 +404	i386	clock_settime64		sys_clock_settime		__ia32_sys_clock_settime
 +405	i386	clock_adjtime64		sys_clock_adjtime		__ia32_sys_clock_adjtime
 +406	i386	clock_getres_time64	sys_clock_getres		__ia32_sys_clock_getres
 +407	i386	clock_nanosleep_time64	sys_clock_nanosleep		__ia32_sys_clock_nanosleep
 +408	i386	timer_gettime64		sys_timer_gettime		__ia32_sys_timer_gettime
 +409	i386	timer_settime64		sys_timer_settime		__ia32_sys_timer_settime
 +410	i386	timerfd_gettime64	sys_timerfd_gettime		__ia32_sys_timerfd_gettime
 +411	i386	timerfd_settime64	sys_timerfd_settime		__ia32_sys_timerfd_settime
 +412	i386	utimensat_time64	sys_utimensat			__ia32_sys_utimensat
 +413	i386	pselect6_time64		sys_pselect6			__ia32_compat_sys_pselect6_time64
 +414	i386	ppoll_time64		sys_ppoll			__ia32_compat_sys_ppoll_time64
 +416	i386	io_pgetevents_time64	sys_io_pgetevents		__ia32_sys_io_pgetevents
 +417	i386	recvmmsg_time64		sys_recvmmsg			__ia32_compat_sys_recvmmsg_time64
 +418	i386	mq_timedsend_time64	sys_mq_timedsend		__ia32_sys_mq_timedsend
 +419	i386	mq_timedreceiv_time64	sys_mq_timedreceive		__ia32_sys_mq_timedreceive
 +420	i386	semtimedop_time64	sys_semtimedop			__ia32_sys_semtimedop
 +421	i386	rt_sigtimedwait_time64	sys_rt_sigtimedwait		__ia32_compat_sys_rt_sigtimedwait_time64
 +422	i386	futex_time64		sys_futex			__ia32_sys_futex
 +423	i386	sched_rr_get_interval_time64	sys_sched_rr_get_interval	__ia32_sys_sched_rr_get_interval
diff --cc include/uapi/asm-generic/unistd.h
index b8626863a90f,b77538af7aca..000000000000
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@@ -740,52 -740,11 +740,54 @@@ __SC_COMP_3264(__NR_io_pgetevents, sys_
  __SYSCALL(__NR_rseq, sys_rseq)
  #define __NR_kexec_file_load 294
  __SYSCALL(__NR_kexec_file_load,     sys_kexec_file_load)
- /* 295 through 402 are unassigned to sync up with generic numbers */
+ #define __NR_pidfd_send_signal 295
+ __SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal)
++/* 296 through 402 are unassigned to sync up with generic numbers */
 +#if __BITS_PER_LONG == 32
 +#define __NR_clock_gettime64 403
 +__SYSCALL(__NR_clock_gettime64, sys_clock_gettime)
 +#define __NR_clock_settime64 404
 +__SYSCALL(__NR_clock_settime64, sys_clock_settime)
 +#define __NR_clock_adjtime64 405
 +__SYSCALL(__NR_clock_adjtime64, sys_clock_adjtime)
 +#define __NR_clock_getres_time64 406
 +__SYSCALL(__NR_clock_getres_time64, sys_clock_getres)
 +#define __NR_clock_nanosleep_time64 407
 +__SYSCALL(__NR_clock_nanosleep_time64, sys_clock_nanosleep)
 +#define __NR_timer_gettime64 408
 +__SYSCALL(__NR_timer_gettime64, sys_timer_gettime)
 +#define __NR_timer_settime64 409
 +__SYSCALL(__NR_timer_settime64, sys_timer_settime)
 +#define __NR_timerfd_gettime64 410
 +__SYSCALL(__NR_timerfd_gettime64, sys_timerfd_gettime)
 +#define __NR_timerfd_settime64 411
 +__SYSCALL(__NR_timerfd_settime64, sys_timerfd_settime)
 +#define __NR_utimensat_time64 412
 +__SYSCALL(__NR_utimensat_time64, sys_utimensat)
 +#define __NR_pselect6_time64 413
 +__SC_COMP(__NR_pselect6_time64, sys_pselect6, compat_sys_pselect6_time64)
 +#define __NR_ppoll_time64 414
 +__SC_COMP(__NR_ppoll_time64, sys_ppoll, compat_sys_ppoll_time64)
 +#define __NR_io_pgetevents_time64 416
 +__SYSCALL(__NR_io_pgetevents_time64, sys_io_pgetevents)
 +#define __NR_recvmmsg_time64 417
 +__SC_COMP(__NR_recvmmsg_time64, sys_recvmmsg, compat_sys_recvmmsg_time64)
 +#define __NR_mq_timedsend_time64 418
 +__SYSCALL(__NR_mq_timedsend_time64, sys_mq_timedsend)
 +#define __NR_mq_timedreceiv_time64 419
 +__SYSCALL(__NR_mq_timedreceiv_time64, sys_mq_timedreceive)
 +#define __NR_semtimedop_time64 420
 +__SYSCALL(__NR_semtimedop_time64, sys_semtimedop)
 +#define __NR_rt_sigtimedwait_time64 421
 +__SC_COMP(__NR_rt_sigtimedwait_time64, sys_rt_sigtimedwait, compat_sys_rt_sigtimedwait_time64)
 +#define __NR_futex_time64 422
 +__SYSCALL(__NR_futex_time64, sys_futex)
 +#define __NR_sched_rr_get_interval_time64 423
 +__SYSCALL(__NR_sched_rr_get_interval_time64, sys_sched_rr_get_interval)
 +#endif
  
  #undef __NR_syscalls
 -#define __NR_syscalls 296
 +#define __NR_syscalls 424
  
  /*
   * 32 bit systems traditionally used different

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

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Arnd Bergmann]

On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the pidfd tree got conflicts in:
>
>   arch/x86/entry/syscalls/syscall_32.tbl
>   include/uapi/asm-generic/unistd.h
>
> between commit:
>
>   10a9a4dd92e6 ("arch: add split IPC system calls where needed")
>   b1788424aa2e ("y2038: add 64-bit time_t syscalls to all 32-bit architectures")
>
> from the y2038 tree and commit:
>
>   3d2991bc7a67 ("signal: add pidfd_send_signal() syscall")
>
> from the pidfd tree.
>
> I fixed it up (see below) 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.

Hi Stephen,

>  +385   i386    io_pgetevents           sys_io_pgetevents_time32        __ia32_compat_sys_io_pgetevents
>   386   i386    rseq                    sys_rseq                        __ia32_sys_rseq
> + 387   i386    pidfd_send_signal       sys_pidfd_send_signal           __ia32_sys_pidfd_send_signal
>  +# room for arch specific syscalls
>  +393   i386    semget                  sys_semget                      __ia32_sys_semget
>  +394   i386    semctl                  sys_semctl                      __ia32_compat_sys_semctl

>   #define __NR_kexec_file_load 294
>   __SYSCALL(__NR_kexec_file_load,     sys_kexec_file_load)
> - /* 295 through 402 are unassigned to sync up with generic numbers */
> + #define __NR_pidfd_send_signal 295
> + __SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal)
> ++/* 296 through 402 are unassigned to sync up with generic numbers */
>  +#if __BITS_PER_LONG == 32
>  +#define __NR_clock_gettime64 403
>  +__SYSCALL(__NR_clock_gettime64, sys_clock_gettime)

If we merge my patches, then any other system calls should get numbers
above 423 on all architectures. Part of what I did in my branch was to
add all missing calls on architectures, and then move up to a common
number for the newly added ones. Your merge works correctly, but
it works against that idea by adding new numbers that conflict with
existing ones on other architectures, e.g. 387 is already assigned
on arm, microblaze, powerpc, and sh, and 294 is assigned almost
everywhere other than the asm-generic version.

      Arnd

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Christian Brauner]

On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote:
> On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > Today's linux-next merge of the pidfd tree got conflicts in:
> >
> >   arch/x86/entry/syscalls/syscall_32.tbl
> >   include/uapi/asm-generic/unistd.h
> >
> > between commit:
> >
> >   10a9a4dd92e6 ("arch: add split IPC system calls where needed")
> >   b1788424aa2e ("y2038: add 64-bit time_t syscalls to all 32-bit architectures")
> >
> > from the y2038 tree and commit:
> >
> >   3d2991bc7a67 ("signal: add pidfd_send_signal() syscall")
> >
> > from the pidfd tree.
> >
> > I fixed it up (see below) 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.
> 
> Hi Stephen,
> 
> >  +385   i386    io_pgetevents           sys_io_pgetevents_time32        __ia32_compat_sys_io_pgetevents
> >   386   i386    rseq                    sys_rseq                        __ia32_sys_rseq
> > + 387   i386    pidfd_send_signal       sys_pidfd_send_signal           __ia32_sys_pidfd_send_signal
> >  +# room for arch specific syscalls
> >  +393   i386    semget                  sys_semget                      __ia32_sys_semget
> >  +394   i386    semctl                  sys_semctl                      __ia32_compat_sys_semctl
> 
> >   #define __NR_kexec_file_load 294
> >   __SYSCALL(__NR_kexec_file_load,     sys_kexec_file_load)
> > - /* 295 through 402 are unassigned to sync up with generic numbers */
> > + #define __NR_pidfd_send_signal 295
> > + __SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal)
> > ++/* 296 through 402 are unassigned to sync up with generic numbers */
> >  +#if __BITS_PER_LONG == 32
> >  +#define __NR_clock_gettime64 403
> >  +__SYSCALL(__NR_clock_gettime64, sys_clock_gettime)
> 
> If we merge my patches, then any other system calls should get numbers
> above 423 on all architectures. Part of what I did in my branch was to
> add all missing calls on architectures, and then move up to a common
> number for the newly added ones. Your merge works correctly, but
> it works against that idea by adding new numbers that conflict with
> existing ones on other architectures, e.g. 387 is already assigned
> on arm, microblaze, powerpc, and sh, and 294 is assigned almost
> everywhere other than the asm-generic version.

Hey Arnd,

I plan on sending the pidfd branch with the new pidfd_send_signal()
syscall for the 5.1 window. Should we somehow coordinate so that our
branches don't conflict? Any suggestions?

Christian

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Arnd Bergmann]

On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner <christian@brauner.io> wrote:
> On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote:
> > On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I plan on sending the pidfd branch with the new pidfd_send_signal()
> syscall for the 5.1 window. Should we somehow coordinate so that our
> branches don't conflict? Any suggestions?

A conflict can't be avoided, but if you pick system call number 427
for pidfd_send_signal, and Jens picks numbers 424 through 426 for
io_uring on all architectures, we can hopefully avoid the renumbering.
Of course, if one or more of the patch series don't make it in or
see a rework that changes the number of new syscalls, then we may
have to change the numbers after all, but we can always hope ;-)

      Arnd

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Christian Brauner]

On Mon, Jan 21, 2019 at 09:15:27PM +0100, Arnd Bergmann wrote:
> On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner <christian@brauner.io> wrote:
> > On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote:
> > > On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I plan on sending the pidfd branch with the new pidfd_send_signal()
> > syscall for the 5.1 window. Should we somehow coordinate so that our
> > branches don't conflict? Any suggestions?
> 
> A conflict can't be avoided, but if you pick system call number 427
> for pidfd_send_signal, and Jens picks numbers 424 through 426 for

That sounds good to me. Since it's only one syscall for the pidfd branch
is there anything that speaks against me using 424? Given that the other
patchset has 4 new syscalls. :)
Jens, any objections?

Christian

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Jens Axboe]

On 1/21/19 1:23 PM, Christian Brauner wrote:
> On Mon, Jan 21, 2019 at 09:15:27PM +0100, Arnd Bergmann wrote:
>> On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner <christian@brauner.io> wrote:
>>> On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote:
>>>> On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> I plan on sending the pidfd branch with the new pidfd_send_signal()
>>> syscall for the 5.1 window. Should we somehow coordinate so that our
>>> branches don't conflict? Any suggestions?
>>
>> A conflict can't be avoided, but if you pick system call number 427
>> for pidfd_send_signal, and Jens picks numbers 424 through 426 for
> 
> That sounds good to me. Since it's only one syscall for the pidfd branch
> is there anything that speaks against me using 424? Given that the other
> patchset has 4 new syscalls. :)
> Jens, any objections?

I'm fine with either one, I'll have to renumber in any case. But it's 3
new syscalls (424, 425, 426), not 4.

Arnd, what's the best way to make this switch now, in my tree? Would be
great if I didn't have to change it again once I make the change.

-- 
Jens Axboe

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Christian Brauner]

On Mon, Jan 21, 2019 at 03:44:17PM -0700, Jens Axboe wrote:
> On 1/21/19 1:23 PM, Christian Brauner wrote:
> > On Mon, Jan 21, 2019 at 09:15:27PM +0100, Arnd Bergmann wrote:
> >> On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner <christian@brauner.io> wrote:
> >>> On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote:
> >>>> On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>>
> >>> I plan on sending the pidfd branch with the new pidfd_send_signal()
> >>> syscall for the 5.1 window. Should we somehow coordinate so that our
> >>> branches don't conflict? Any suggestions?
> >>
> >> A conflict can't be avoided, but if you pick system call number 427
> >> for pidfd_send_signal, and Jens picks numbers 424 through 426 for
> > 
> > That sounds good to me. Since it's only one syscall for the pidfd branch
> > is there anything that speaks against me using 424? Given that the other
> > patchset has 4 new syscalls. :)
> > Jens, any objections?
> 
> I'm fine with either one, I'll have to renumber in any case. But it's 3
> new syscalls (424, 425, 426), not 4.
> 
> Arnd, what's the best way to make this switch now, in my tree? Would be

Yeah, I'd like to know that as well.

Christian

> great if I didn't have to change it again once I make the change.

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Arnd Bergmann]

On Mon, Jan 21, 2019 at 11:48 PM Christian Brauner <christian@brauner.io> wrote:
>
> On Mon, Jan 21, 2019 at 03:44:17PM -0700, Jens Axboe wrote:
> > On 1/21/19 1:23 PM, Christian Brauner wrote:
> > > On Mon, Jan 21, 2019 at 09:15:27PM +0100, Arnd Bergmann wrote:
> > >> On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner <christian@brauner.io> wrote:
> > >>> On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote:
> > >>>> On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >>>
> > >>> I plan on sending the pidfd branch with the new pidfd_send_signal()
> > >>> syscall for the 5.1 window. Should we somehow coordinate so that our
> > >>> branches don't conflict? Any suggestions?
> > >>
> > >> A conflict can't be avoided, but if you pick system call number 427
> > >> for pidfd_send_signal, and Jens picks numbers 424 through 426 for
> > >
> > > That sounds good to me. Since it's only one syscall for the pidfd branch
> > > is there anything that speaks against me using 424? Given that the other
> > > patchset has 4 new syscalls. :)
> > > Jens, any objections?
> >
> > I'm fine with either one, I'll have to renumber in any case. But it's 3
> > new syscalls (424, 425, 426), not 4.
> >
> > Arnd, what's the best way to make this switch now, in my tree? Would be
>
> Yeah, I'd like to know that as well.
>
> > great if I didn't have to change it again once I make the change.

I'd suggest that you each just take the numbers we talked about and
add them in your respective git trees, at the end of the current tables.

Stephen and Linus can then do a trivial add/add merge between the
three trees that does not involve changing any of the lines besides
keeping them in the right order. The result should then be

== arch/x86/entry/syscalls/syscall_32.tbl
422    i386    futex_time64        sys_futex            __ia32_sys_futex
423    i386    sched_rr_get_interval_time64
sys_sched_rr_get_interval    __ia32_sys_sched_rr_get_interval
424    i386    pidfd_send_signal     sys_pidfd_send_signal
__ia32_sys_pidfd_send_signal
425    i386    io_uring_setup          sys_io_uring_setup
__ia32_compat_sys_io_uring_setup
426    i386    io_uring_enter          sys_io_uring_enter
 __ia32_sys_io_uring_enter
427    i386    io_uring_register       sys_io_uring_register
__ia32_sys_io_uring_register

== arch/x86/entry/syscalls/syscall_64.tbl
...
334    common  rseq                    __x64_sys_rseq
# don't use numbers 387 through 423, add new calls after the last
# 'common' entry
424    common    pidfd_send_signal      __x64_sys_pidfd_send_signal
425    common    io_uring_setup           __x64_sys_io_uring_setup
426    common    io_uring_enter           __x64_sys_io_uring_enter
427    common    io_uring_register        __x64_sys_io_uring_register
#
# x32-specific system call numbers start at 512 to avoid cache impact
# for native 64-bit operation. The __x32_compat_sys stubs are created
# on-the-fly for compat_sys_*() compatibility system calls if X86_X32
# is defined.
#
512     x32     rt_sigaction            __x32_compat_sys_rt_sigaction
...

My hope is that in the future, any new system call will get added to
all 16 syscall.tbl files at once, but let's maybe not do this for 5.1
yet, since that only causes more conflicts. I can simply follow up
with a patch to add pidfd_send_signal and io_uring_* everywhere
during the merge window.

      Arnd

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Christian Brauner]

On Tue, Jan 22, 2019 at 10:26:56AM +0100, Arnd Bergmann wrote:
> On Mon, Jan 21, 2019 at 11:48 PM Christian Brauner <christian@brauner.io> wrote:
> >
> > On Mon, Jan 21, 2019 at 03:44:17PM -0700, Jens Axboe wrote:
> > > On 1/21/19 1:23 PM, Christian Brauner wrote:
> > > > On Mon, Jan 21, 2019 at 09:15:27PM +0100, Arnd Bergmann wrote:
> > > >> On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner <christian@brauner.io> wrote:
> > > >>> On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote:
> > > >>>> On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >>>
> > > >>> I plan on sending the pidfd branch with the new pidfd_send_signal()
> > > >>> syscall for the 5.1 window. Should we somehow coordinate so that our
> > > >>> branches don't conflict? Any suggestions?
> > > >>
> > > >> A conflict can't be avoided, but if you pick system call number 427
> > > >> for pidfd_send_signal, and Jens picks numbers 424 through 426 for
> > > >
> > > > That sounds good to me. Since it's only one syscall for the pidfd branch
> > > > is there anything that speaks against me using 424? Given that the other
> > > > patchset has 4 new syscalls. :)
> > > > Jens, any objections?
> > >
> > > I'm fine with either one, I'll have to renumber in any case. But it's 3
> > > new syscalls (424, 425, 426), not 4.
> > >
> > > Arnd, what's the best way to make this switch now, in my tree? Would be
> >
> > Yeah, I'd like to know that as well.
> >
> > > great if I didn't have to change it again once I make the change.
> 
> I'd suggest that you each just take the numbers we talked about and
> add them in your respective git trees, at the end of the current tables.

Great! Will do that today before Stephen does a new merge for -next.

> 
> Stephen and Linus can then do a trivial add/add merge between the
> three trees that does not involve changing any of the lines besides
> keeping them in the right order. The result should then be
> 
> == arch/x86/entry/syscalls/syscall_32.tbl
> 422    i386    futex_time64        sys_futex            __ia32_sys_futex
> 423    i386    sched_rr_get_interval_time64
> sys_sched_rr_get_interval    __ia32_sys_sched_rr_get_interval
> 424    i386    pidfd_send_signal     sys_pidfd_send_signal
> __ia32_sys_pidfd_send_signal
> 425    i386    io_uring_setup          sys_io_uring_setup
> __ia32_compat_sys_io_uring_setup
> 426    i386    io_uring_enter          sys_io_uring_enter
>  __ia32_sys_io_uring_enter
> 427    i386    io_uring_register       sys_io_uring_register
> __ia32_sys_io_uring_register
> 
> == arch/x86/entry/syscalls/syscall_64.tbl
> ...
> 334    common  rseq                    __x64_sys_rseq
> # don't use numbers 387 through 423, add new calls after the last
> # 'common' entry
> 424    common    pidfd_send_signal      __x64_sys_pidfd_send_signal
> 425    common    io_uring_setup           __x64_sys_io_uring_setup
> 426    common    io_uring_enter           __x64_sys_io_uring_enter
> 427    common    io_uring_register        __x64_sys_io_uring_register
> #
> # x32-specific system call numbers start at 512 to avoid cache impact
> # for native 64-bit operation. The __x32_compat_sys stubs are created
> # on-the-fly for compat_sys_*() compatibility system calls if X86_X32
> # is defined.
> #
> 512     x32     rt_sigaction            __x32_compat_sys_rt_sigaction
> ...
> 
> My hope is that in the future, any new system call will get added to
> all 16 syscall.tbl files at once, but let's maybe not do this for 5.1
> yet, since that only causes more conflicts. I can simply follow up
> with a patch to add pidfd_send_signal and io_uring_* everywhere
> during the merge window.

Sounds good to me.

Thanks Arnd!
Christian

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Christian Brauner]

On Tue, Jan 22, 2019 at 10:31:46AM +0100, Christian Brauner wrote:
> On Tue, Jan 22, 2019 at 10:26:56AM +0100, Arnd Bergmann wrote:
> > On Mon, Jan 21, 2019 at 11:48 PM Christian Brauner <christian@brauner.io> wrote:
> > >
> > > On Mon, Jan 21, 2019 at 03:44:17PM -0700, Jens Axboe wrote:
> > > > On 1/21/19 1:23 PM, Christian Brauner wrote:
> > > > > On Mon, Jan 21, 2019 at 09:15:27PM +0100, Arnd Bergmann wrote:
> > > > >> On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner <christian@brauner.io> wrote:
> > > > >>> On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote:
> > > > >>>> On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > >>>
> > > > >>> I plan on sending the pidfd branch with the new pidfd_send_signal()
> > > > >>> syscall for the 5.1 window. Should we somehow coordinate so that our
> > > > >>> branches don't conflict? Any suggestions?
> > > > >>
> > > > >> A conflict can't be avoided, but if you pick system call number 427
> > > > >> for pidfd_send_signal, and Jens picks numbers 424 through 426 for
> > > > >
> > > > > That sounds good to me. Since it's only one syscall for the pidfd branch
> > > > > is there anything that speaks against me using 424? Given that the other
> > > > > patchset has 4 new syscalls. :)
> > > > > Jens, any objections?
> > > >
> > > > I'm fine with either one, I'll have to renumber in any case. But it's 3
> > > > new syscalls (424, 425, 426), not 4.
> > > >
> > > > Arnd, what's the best way to make this switch now, in my tree? Would be
> > >
> > > Yeah, I'd like to know that as well.
> > >
> > > > great if I didn't have to change it again once I make the change.
> > 
> > I'd suggest that you each just take the numbers we talked about and
> > add them in your respective git trees, at the end of the current tables.

What should we do about unistd.h? We can't just bump that to 42*, right?

Christian

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Arnd Bergmann]

On Tue, Jan 22, 2019 at 11:30 AM Christian Brauner <christian@brauner.io> wrote:
>
> On Tue, Jan 22, 2019 at 10:31:46AM +0100, Christian Brauner wrote:
> > On Tue, Jan 22, 2019 at 10:26:56AM +0100, Arnd Bergmann wrote:
> > > On Mon, Jan 21, 2019 at 11:48 PM Christian Brauner <christian@brauner.io> wrote:
> > > >
> > > > On Mon, Jan 21, 2019 at 03:44:17PM -0700, Jens Axboe wrote:
> > > > > On 1/21/19 1:23 PM, Christian Brauner wrote:
> > > > > > On Mon, Jan 21, 2019 at 09:15:27PM +0100, Arnd Bergmann wrote:
> > > > > >> On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner <christian@brauner.io> wrote:
> > > > > >>> On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote:
> > > > > >>>> On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > >>>
> > > > > >>> I plan on sending the pidfd branch with the new pidfd_send_signal()
> > > > > >>> syscall for the 5.1 window. Should we somehow coordinate so that our
> > > > > >>> branches don't conflict? Any suggestions?
> > > > > >>
> > > > > >> A conflict can't be avoided, but if you pick system call number 427
> > > > > >> for pidfd_send_signal, and Jens picks numbers 424 through 426 for
> > > > > >
> > > > > > That sounds good to me. Since it's only one syscall for the pidfd branch
> > > > > > is there anything that speaks against me using 424? Given that the other
> > > > > > patchset has 4 new syscalls. :)
> > > > > > Jens, any objections?
> > > > >
> > > > > I'm fine with either one, I'll have to renumber in any case. But it's 3
> > > > > new syscalls (424, 425, 426), not 4.
> > > > >
> > > > > Arnd, what's the best way to make this switch now, in my tree? Would be
> > > >
> > > > Yeah, I'd like to know that as well.
> > > >
> > > > > great if I didn't have to change it again once I make the change.
> > >
> > > I'd suggest that you each just take the numbers we talked about and
> > > add them in your respective git trees, at the end of the current tables.
>
> What should we do about unistd.h? We can't just bump that to 42*, right?

Do you mean the asm-generic uapi header? In my current series, I do that:

#define __NR_rseq 293
__SYSCALL(__NR_rseq, sys_rseq)
#define __NR_kexec_file_load 294
__SYSCALL(__NR_kexec_file_load,     sys_kexec_file_load)
/* 295 through 402 are unassigned to sync up with generic numbers, don't use */
#if __BITS_PER_LONG == 32
#define __NR_clock_gettime64 403
__SYSCALL(__NR_clock_gettime64, sys_clock_gettime)
#define __NR_clock_settime64 404
...
#define __NR_rt_sigtimedwait_time64 421
__SC_COMP(__NR_rt_sigtimedwait_time64, sys_rt_sigtimedwait,
compat_sys_rt_sigtimedwait_time64)
#define __NR_futex_time64 422
__SYSCALL(__NR_futex_time64, sys_futex)
#define __NR_sched_rr_get_interval_time64 423
__SYSCALL(__NR_sched_rr_get_interval_time64, sys_sched_rr_get_interval)
#endif
#undef __NR_syscalls
#define __NR_syscalls 424

I've tried to feedback on that, but so far nobody has spoken out against
skipping the 107 numbers here, though Russell felt that the idea of
using the same numbers everywhere might not work out.

     Arnd

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Christian Brauner]

On Tue, Jan 22, 2019 at 11:48:12AM +0100, Arnd Bergmann wrote:
> On Tue, Jan 22, 2019 at 11:30 AM Christian Brauner <christian@brauner.io> wrote:
> >
> > On Tue, Jan 22, 2019 at 10:31:46AM +0100, Christian Brauner wrote:
> > > On Tue, Jan 22, 2019 at 10:26:56AM +0100, Arnd Bergmann wrote:
> > > > On Mon, Jan 21, 2019 at 11:48 PM Christian Brauner <christian@brauner.io> wrote:
> > > > >
> > > > > On Mon, Jan 21, 2019 at 03:44:17PM -0700, Jens Axboe wrote:
> > > > > > On 1/21/19 1:23 PM, Christian Brauner wrote:
> > > > > > > On Mon, Jan 21, 2019 at 09:15:27PM +0100, Arnd Bergmann wrote:
> > > > > > >> On Mon, Jan 21, 2019 at 8:13 PM Christian Brauner <christian@brauner.io> wrote:
> > > > > > >>> On Mon, Jan 21, 2019 at 06:16:22PM +0100, Arnd Bergmann wrote:
> > > > > > >>>> On Mon, Jan 21, 2019 at 4:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > > >>>
> > > > > > >>> I plan on sending the pidfd branch with the new pidfd_send_signal()
> > > > > > >>> syscall for the 5.1 window. Should we somehow coordinate so that our
> > > > > > >>> branches don't conflict? Any suggestions?
> > > > > > >>
> > > > > > >> A conflict can't be avoided, but if you pick system call number 427
> > > > > > >> for pidfd_send_signal, and Jens picks numbers 424 through 426 for
> > > > > > >
> > > > > > > That sounds good to me. Since it's only one syscall for the pidfd branch
> > > > > > > is there anything that speaks against me using 424? Given that the other
> > > > > > > patchset has 4 new syscalls. :)
> > > > > > > Jens, any objections?
> > > > > >
> > > > > > I'm fine with either one, I'll have to renumber in any case. But it's 3
> > > > > > new syscalls (424, 425, 426), not 4.
> > > > > >
> > > > > > Arnd, what's the best way to make this switch now, in my tree? Would be
> > > > >
> > > > > Yeah, I'd like to know that as well.
> > > > >
> > > > > > great if I didn't have to change it again once I make the change.
> > > >
> > > > I'd suggest that you each just take the numbers we talked about and
> > > > add them in your respective git trees, at the end of the current tables.
> >
> > What should we do about unistd.h? We can't just bump that to 42*, right?
> 
> Do you mean the asm-generic uapi header? In my current series, I do that:

Yes. My idea was to only change pidfd_send_signal's entry to 424 and
leave the other ones untouched:

 #
 # x32-specific system call numbers start at 512 to avoid cache impact
diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
index b77538af7aca..4d86d0787d99 100644
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@ -740,7 +740,7 @@ __SC_COMP(__NR_io_pgetevents, sys_io_pgetevents, compat_sys_io_pgetevents)
 __SYSCALL(__NR_rseq, sys_rseq)
 #define __NR_kexec_file_load 294
 __SYSCALL(__NR_kexec_file_load,     sys_kexec_file_load)
-#define __NR_pidfd_send_signal 295
+#define __NR_pidfd_send_signal 424
 __SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal)

and also leave

#undef __NR_syscalls
#define __NR_syscalls 296

Does that work to avoid the merge conflict or do you need something
more?

Christian

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Arnd Bergmann]

On Tue, Jan 22, 2019 at 11:57 AM Christian Brauner <christian@brauner.io> wrote:
> On Tue, Jan 22, 2019 at 11:48:12AM +0100, Arnd Bergmann wrote:

> > Do you mean the asm-generic uapi header? In my current series, I do that:
>
> Yes. My idea was to only change pidfd_send_signal's entry to 424 and
> leave the other ones untouched:
>
>  #
>  # x32-specific system call numbers start at 512 to avoid cache impact
> diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
> index b77538af7aca..4d86d0787d99 100644
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@ -740,7 +740,7 @@ __SC_COMP(__NR_io_pgetevents, sys_io_pgetevents, compat_sys_io_pgetevents)
>  __SYSCALL(__NR_rseq, sys_rseq)
>  #define __NR_kexec_file_load 294
>  __SYSCALL(__NR_kexec_file_load,     sys_kexec_file_load)
> -#define __NR_pidfd_send_signal 295
> +#define __NR_pidfd_send_signal 424
>  __SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal)
>
> and also leave

Yes, that looks good.

> #undef __NR_syscalls
> #define __NR_syscalls 296
>
> Does that work to avoid the merge conflict or do you need something
> more?

You need to change __NR_syscalls to 425 as well. This will
clearly create a conflict, but then the resolution will be to pick
the correct (a.k.a. highest) number, rather than remembering
to update it manually.

      Arnd

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Christian Brauner]

On Tue, Jan 22, 2019 at 12:42:44PM +0100, Arnd Bergmann wrote:
> On Tue, Jan 22, 2019 at 11:57 AM Christian Brauner <christian@brauner.io> wrote:
> > On Tue, Jan 22, 2019 at 11:48:12AM +0100, Arnd Bergmann wrote:
> 
> > > Do you mean the asm-generic uapi header? In my current series, I do that:
> >
> > Yes. My idea was to only change pidfd_send_signal's entry to 424 and
> > leave the other ones untouched:
> >
> >  #
> >  # x32-specific system call numbers start at 512 to avoid cache impact
> > diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
> > index b77538af7aca..4d86d0787d99 100644
> > --- a/include/uapi/asm-generic/unistd.h
> > +++ b/include/uapi/asm-generic/unistd.h
> > @@ -740,7 +740,7 @@ __SC_COMP(__NR_io_pgetevents, sys_io_pgetevents, compat_sys_io_pgetevents)
> >  __SYSCALL(__NR_rseq, sys_rseq)
> >  #define __NR_kexec_file_load 294
> >  __SYSCALL(__NR_kexec_file_load,     sys_kexec_file_load)
> > -#define __NR_pidfd_send_signal 295
> > +#define __NR_pidfd_send_signal 424
> >  __SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal)
> >
> > and also leave
> 
> Yes, that looks good.
> 
> > #undef __NR_syscalls
> > #define __NR_syscalls 296
> >
> > Does that work to avoid the merge conflict or do you need something
> > more?
> 
> You need to change __NR_syscalls to 425 as well. This will
> clearly create a conflict, but then the resolution will be to pick
> the correct (a.k.a. highest) number, rather than remembering
> to update it manually.

Hm, ok. Wasn't sure if that would confuse people.

Ok, when I sent my PR I will make a note in the PR that this branch is
aligned to create only minimal conflicts with your y2038 branch. The
patch carries your ack already so this should be good.

Thanks Arnd!
Christian

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Christian Brauner]

On Tue, Jan 22, 2019 at 12:46:56PM +0100, Christian Brauner wrote:
> On Tue, Jan 22, 2019 at 12:42:44PM +0100, Arnd Bergmann wrote:
> > On Tue, Jan 22, 2019 at 11:57 AM Christian Brauner <christian@brauner.io> wrote:
> > > On Tue, Jan 22, 2019 at 11:48:12AM +0100, Arnd Bergmann wrote:
> > 
> > > > Do you mean the asm-generic uapi header? In my current series, I do that:
> > >
> > > Yes. My idea was to only change pidfd_send_signal's entry to 424 and
> > > leave the other ones untouched:
> > >
> > >  #
> > >  # x32-specific system call numbers start at 512 to avoid cache impact
> > > diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
> > > index b77538af7aca..4d86d0787d99 100644
> > > --- a/include/uapi/asm-generic/unistd.h
> > > +++ b/include/uapi/asm-generic/unistd.h
> > > @@ -740,7 +740,7 @@ __SC_COMP(__NR_io_pgetevents, sys_io_pgetevents, compat_sys_io_pgetevents)
> > >  __SYSCALL(__NR_rseq, sys_rseq)
> > >  #define __NR_kexec_file_load 294
> > >  __SYSCALL(__NR_kexec_file_load,     sys_kexec_file_load)
> > > -#define __NR_pidfd_send_signal 295
> > > +#define __NR_pidfd_send_signal 424
> > >  __SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal)
> > >
> > > and also leave
> > 
> > Yes, that looks good.
> > 
> > > #undef __NR_syscalls
> > > #define __NR_syscalls 296
> > >
> > > Does that work to avoid the merge conflict or do you need something
> > > more?
> > 
> > You need to change __NR_syscalls to 425 as well. This will
> > clearly create a conflict, but then the resolution will be to pick
> > the correct (a.k.a. highest) number, rather than remembering
> > to update it manually.
> 
> Hm, ok. Wasn't sure if that would confuse people.
> 
> Ok, when I sent my PR I will make a note in the PR that this branch is
> aligned to create only minimal conflicts with your y2038 branch. The
> patch carries your ack already so this should be good.

Arnd, in case you care to take a look
https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=for-next

Thanks!
Christian

Re: linux-next: manual merge of the pidfd tree with the y2038 tree

[Arnd Bergmann]

On Tue, Jan 22, 2019 at 1:24 PM Christian Brauner <christian@brauner.io> wrote:
> On Tue, Jan 22, 2019 at 12:46:56PM +0100, Christian Brauner wrote:
> > On Tue, Jan 22, 2019 at 12:42:44PM +0100, Arnd Bergmann wrote:
> > >
> > > You need to change __NR_syscalls to 425 as well. This will
> > > clearly create a conflict, but then the resolution will be to pick
> > > the correct (a.k.a. highest) number, rather than remembering
> > > to update it manually.
> >
> > Hm, ok. Wasn't sure if that would confuse people.
> >
> > Ok, when I sent my PR I will make a note in the PR that this branch is
> > aligned to create only minimal conflicts with your y2038 branch. The
> > patch carries your ack already so this should be good.

My point was just that __NR_syscalls has to be one more than the highest
syscall number, otherwise we get a build failure on architectures that
create an array of __NR_syscalls entries.

> Arnd, in case you care to take a look
> https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=for-next

Looks good to me.

      Arnd

linux-next: manual merge of the pidfd tree with the y2038 tree

[Stephen Rothwell]

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

Hi all,

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

  arch/x86/entry/syscalls/syscall_32.tbl
  arch/x86/entry/syscalls/syscall_64.tbl
  include/uapi/asm-generic/unistd.h

between commits:

  63a96220ad45 ("arch: add split IPC system calls where needed")
  0bd4bb9c5612 ("y2038: add 64-bit time_t syscalls to all 32-bit architectures")

from the y2038 tree and commit:

  3d2991bc7a67 ("signal: add pidfd_send_signal() syscall")

from the pidfd tree.

I fixed it up (I hope this resolution is better - see below) 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

diff --cc arch/x86/entry/syscalls/syscall_32.tbl
index 955ab6a3b61f,6804c1e84b36..000000000000
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@@ -396,36 -396,6 +396,37 @@@
  382	i386	pkey_free		sys_pkey_free			__ia32_sys_pkey_free
  383	i386	statx			sys_statx			__ia32_sys_statx
  384	i386	arch_prctl		sys_arch_prctl			__ia32_compat_sys_arch_prctl
 -385	i386	io_pgetevents		sys_io_pgetevents		__ia32_compat_sys_io_pgetevents
 +385	i386	io_pgetevents		sys_io_pgetevents_time32	__ia32_compat_sys_io_pgetevents
  386	i386	rseq			sys_rseq			__ia32_sys_rseq
 -387	i386	pidfd_send_signal	sys_pidfd_send_signal		__ia32_sys_pidfd_send_signal
 +# don't use numbers 387 through 392, add new calls at the end
 +393	i386	semget			sys_semget    			__ia32_sys_semget
 +394	i386	semctl			sys_semctl    			__ia32_compat_sys_semctl
 +395	i386	shmget			sys_shmget    			__ia32_sys_shmget
 +396	i386	shmctl			sys_shmctl    			__ia32_compat_sys_shmctl
 +397	i386	shmat			sys_shmat     			__ia32_compat_sys_shmat
 +398	i386	shmdt			sys_shmdt     			__ia32_sys_shmdt
 +399	i386	msgget			sys_msgget    			__ia32_sys_msgget
 +400	i386	msgsnd			sys_msgsnd    			__ia32_compat_sys_msgsnd
 +401	i386	msgrcv			sys_msgrcv    			__ia32_compat_sys_msgrcv
 +402	i386	msgctl			sys_msgctl    			__ia32_compat_sys_msgctl
 +403	i386	clock_gettime64		sys_clock_gettime		__ia32_sys_clock_gettime
 +404	i386	clock_settime64		sys_clock_settime		__ia32_sys_clock_settime
 +405	i386	clock_adjtime64		sys_clock_adjtime		__ia32_sys_clock_adjtime
 +406	i386	clock_getres_time64	sys_clock_getres		__ia32_sys_clock_getres
 +407	i386	clock_nanosleep_time64	sys_clock_nanosleep		__ia32_sys_clock_nanosleep
 +408	i386	timer_gettime64		sys_timer_gettime		__ia32_sys_timer_gettime
 +409	i386	timer_settime64		sys_timer_settime		__ia32_sys_timer_settime
 +410	i386	timerfd_gettime64	sys_timerfd_gettime		__ia32_sys_timerfd_gettime
 +411	i386	timerfd_settime64	sys_timerfd_settime		__ia32_sys_timerfd_settime
 +412	i386	utimensat_time64	sys_utimensat			__ia32_sys_utimensat
 +413	i386	pselect6_time64		sys_pselect6			__ia32_compat_sys_pselect6_time64
 +414	i386	ppoll_time64		sys_ppoll			__ia32_compat_sys_ppoll_time64
 +416	i386	io_pgetevents_time64	sys_io_pgetevents		__ia32_sys_io_pgetevents
 +417	i386	recvmmsg_time64		sys_recvmmsg			__ia32_compat_sys_recvmmsg_time64
 +418	i386	mq_timedsend_time64	sys_mq_timedsend		__ia32_sys_mq_timedsend
 +419	i386	mq_timedreceive_time64	sys_mq_timedreceive		__ia32_sys_mq_timedreceive
 +420	i386	semtimedop_time64	sys_semtimedop			__ia32_sys_semtimedop
 +421	i386	rt_sigtimedwait_time64	sys_rt_sigtimedwait		__ia32_compat_sys_rt_sigtimedwait_time64
 +422	i386	futex_time64		sys_futex			__ia32_sys_futex
 +423	i386	sched_rr_get_interval_time64	sys_sched_rr_get_interval	__ia32_sys_sched_rr_get_interval
++424	i386	pidfd_send_signal	sys_pidfd_send_signal		__ia32_sys_pidfd_send_signal
diff --cc arch/x86/entry/syscalls/syscall_64.tbl
index 2ae92fddb6d5,aa4b858fa0f1..000000000000
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@@ -343,8 -343,7 +343,9 @@@
  332	common	statx			__x64_sys_statx
  333	common	io_pgetevents		__x64_sys_io_pgetevents
  334	common	rseq			__x64_sys_rseq
 -335	common	pidfd_send_signal	__x64_sys_pidfd_send_signal
 +# don't use numbers 387 through 423, add new calls after the last
 +# 'common' entry
++424	common	pidfd_send_signal	__x64_sys_pidfd_send_signal
  
  #
  # x32-specific system call numbers start at 512 to avoid cache impact
diff --cc include/uapi/asm-generic/unistd.h
index acf9a07ab2ff,b77538af7aca..000000000000
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@@ -740,52 -740,11 +740,54 @@@ __SC_COMP_3264(__NR_io_pgetevents, sys_
  __SYSCALL(__NR_rseq, sys_rseq)
  #define __NR_kexec_file_load 294
  __SYSCALL(__NR_kexec_file_load,     sys_kexec_file_load)
 -#define __NR_pidfd_send_signal 295
 +/* 295 through 402 are unassigned to sync up with generic numbers, don't use */
 +#if __BITS_PER_LONG == 32
 +#define __NR_clock_gettime64 403
 +__SYSCALL(__NR_clock_gettime64, sys_clock_gettime)
 +#define __NR_clock_settime64 404
 +__SYSCALL(__NR_clock_settime64, sys_clock_settime)
 +#define __NR_clock_adjtime64 405
 +__SYSCALL(__NR_clock_adjtime64, sys_clock_adjtime)
 +#define __NR_clock_getres_time64 406
 +__SYSCALL(__NR_clock_getres_time64, sys_clock_getres)
 +#define __NR_clock_nanosleep_time64 407
 +__SYSCALL(__NR_clock_nanosleep_time64, sys_clock_nanosleep)
 +#define __NR_timer_gettime64 408
 +__SYSCALL(__NR_timer_gettime64, sys_timer_gettime)
 +#define __NR_timer_settime64 409
 +__SYSCALL(__NR_timer_settime64, sys_timer_settime)
 +#define __NR_timerfd_gettime64 410
 +__SYSCALL(__NR_timerfd_gettime64, sys_timerfd_gettime)
 +#define __NR_timerfd_settime64 411
 +__SYSCALL(__NR_timerfd_settime64, sys_timerfd_settime)
 +#define __NR_utimensat_time64 412
 +__SYSCALL(__NR_utimensat_time64, sys_utimensat)
 +#define __NR_pselect6_time64 413
 +__SC_COMP(__NR_pselect6_time64, sys_pselect6, compat_sys_pselect6_time64)
 +#define __NR_ppoll_time64 414
 +__SC_COMP(__NR_ppoll_time64, sys_ppoll, compat_sys_ppoll_time64)
 +#define __NR_io_pgetevents_time64 416
 +__SYSCALL(__NR_io_pgetevents_time64, sys_io_pgetevents)
 +#define __NR_recvmmsg_time64 417
 +__SC_COMP(__NR_recvmmsg_time64, sys_recvmmsg, compat_sys_recvmmsg_time64)
 +#define __NR_mq_timedsend_time64 418
 +__SYSCALL(__NR_mq_timedsend_time64, sys_mq_timedsend)
 +#define __NR_mq_timedreceive_time64 419
 +__SYSCALL(__NR_mq_timedreceive_time64, sys_mq_timedreceive)
 +#define __NR_semtimedop_time64 420
 +__SYSCALL(__NR_semtimedop_time64, sys_semtimedop)
 +#define __NR_rt_sigtimedwait_time64 421
 +__SC_COMP(__NR_rt_sigtimedwait_time64, sys_rt_sigtimedwait, compat_sys_rt_sigtimedwait_time64)
 +#define __NR_futex_time64 422
 +__SYSCALL(__NR_futex_time64, sys_futex)
 +#define __NR_sched_rr_get_interval_time64 423
 +__SYSCALL(__NR_sched_rr_get_interval_time64, sys_sched_rr_get_interval)
 +#endif
++#define __NR_pidfd_send_signal 424
+ __SYSCALL(__NR_pidfd_send_signal, sys_pidfd_send_signal)
  
  #undef __NR_syscalls
- #define __NR_syscalls 424
 -#define __NR_syscalls 296
++#define __NR_syscalls 425
  
  /*
   * 32 bit systems traditionally used different

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