* linux-next: manual merge of the pidfd tree with the y2038 tree
@ 2019-01-22 3:10 Stephen Rothwell
2019-02-13 5:22 ` linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees) Stephen Rothwell
0 siblings, 1 reply; 24+ messages in thread
From: Stephen Rothwell @ 2019-01-22 3:10 UTC (permalink / raw)
To: Christian Brauner, Arnd Bergmann
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees)
2019-01-22 3:10 linux-next: manual merge of the pidfd tree with the y2038 tree Stephen Rothwell
@ 2019-02-13 5:22 ` Stephen Rothwell
2019-02-13 12:57 ` Arnd Bergmann
0 siblings, 1 reply; 24+ messages in thread
From: Stephen Rothwell @ 2019-02-13 5:22 UTC (permalink / raw)
To: Christian Brauner, Jens Axboe, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra
Cc: Arnd Bergmann, Linux Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 8038 bytes --]
Hi all,
On Tue, 22 Jan 2019 14:10:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> 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.
This is now a conflict between the block, tip and pidfd trees. The
resolution now looks like below.
> 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 8da78595d69d,234d91df8ca6..000000000000
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@@ -396,39 -396,6 +396,40 @@@
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
+# 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
+425 i386 io_uring_setup sys_io_uring_setup __ia32_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
diff --cc arch/x86/entry/syscalls/syscall_64.tbl
index c768447f97ec,58f4b3ad4fe0..000000000000
--- a/arch/x86/entry/syscalls/syscall_64.tbl
+++ b/arch/x86/entry/syscalls/syscall_64.tbl
@@@ -343,11 -343,7 +343,12 @@@
332 common statx __x64_sys_statx
333 common io_pgetevents __x64_sys_io_pgetevents
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
diff --cc include/uapi/asm-generic/unistd.h
index 94fde9a14830,c861e7d1053b..000000000000
--- a/include/uapi/asm-generic/unistd.h
+++ b/include/uapi/asm-generic/unistd.h
@@@ -740,58 -740,11 +740,60 @@@ __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, 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)
+#define __NR_io_uring_setup 425
+__SYSCALL(__NR_io_uring_setup, sys_io_uring_setup)
+#define __NR_io_uring_enter 426
+__SYSCALL(__NR_io_uring_enter, sys_io_uring_enter)
+#define __NR_io_uring_register 427
+__SYSCALL(__NR_io_uring_register, sys_io_uring_register)
#undef __NR_syscalls
-#define __NR_syscalls 425
+#define __NR_syscalls 428
/*
* 32 bit systems traditionally used different
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees)
2019-02-13 5:22 ` linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees) Stephen Rothwell
@ 2019-02-13 12:57 ` Arnd Bergmann
2019-03-11 8:36 ` New syscalls (was: Re: linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees)) Geert Uytterhoeven
0 siblings, 1 reply; 24+ messages in thread
From: Arnd Bergmann @ 2019-02-13 12:57 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Christian Brauner, Jens Axboe, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Linux Next Mailing List,
Linux Kernel Mailing List
On Wed, Feb 13, 2019 at 6:22 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Tue, 22 Jan 2019 14:10:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > 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.
>
> This is now a conflict between the block, tip and pidfd trees. The
> resolution now looks like below.
Checked it again, still looks good. Thanks,
Arnd
^ permalink raw reply [flat|nested] 24+ messages in thread
* New syscalls (was: Re: linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees))
2019-02-13 12:57 ` Arnd Bergmann
@ 2019-03-11 8:36 ` Geert Uytterhoeven
2019-03-11 21:38 ` Arnd Bergmann
0 siblings, 1 reply; 24+ messages in thread
From: Geert Uytterhoeven @ 2019-03-11 8:36 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Rothwell, Christian Brauner, Jens Axboe, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Linux Next Mailing List, Linux Kernel Mailing List, Linux-Arch
Hi Arnd,
On Wed, Feb 13, 2019 at 3:22 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Wed, Feb 13, 2019 at 6:22 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > On Tue, 22 Jan 2019 14:10:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > 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.
> >
> > This is now a conflict between the block, tip and pidfd trees. The
> > resolution now looks like below.
>
> Checked it again, still looks good. Thanks,
What's the plan with adding new syscalls to all architectures?
+ <stdin>: warning: #warning syscall io_uring_enter not implemented
[-Wcpp]: => 1481:2
+ <stdin>: warning: #warning syscall io_uring_register not
implemented [-Wcpp]: => 1484:2
+ <stdin>: warning: #warning syscall io_uring_setup not implemented
[-Wcpp]: => 1478:2
and more seem to be planned for this merge window.
Shall each architcture maintainer take care of this hxxself, or will
this be done in
a coordinated way?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: New syscalls (was: Re: linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees))
2019-03-11 8:36 ` New syscalls (was: Re: linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees)) Geert Uytterhoeven
@ 2019-03-11 21:38 ` Arnd Bergmann
2019-03-11 21:43 ` Christian Brauner
0 siblings, 1 reply; 24+ messages in thread
From: Arnd Bergmann @ 2019-03-11 21:38 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Rothwell, Christian Brauner, Jens Axboe, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Linux Next Mailing List, Linux Kernel Mailing List, Linux-Arch
On Mon, Mar 11, 2019 at 9:36 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Wed, Feb 13, 2019 at 3:22 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wed, Feb 13, 2019 at 6:22 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > On Tue, 22 Jan 2019 14:10:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > 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.
> > >
> > > This is now a conflict between the block, tip and pidfd trees. The
> > > resolution now looks like below.
> >
> > Checked it again, still looks good. Thanks,
>
> What's the plan with adding new syscalls to all architectures?
>
> + <stdin>: warning: #warning syscall io_uring_enter not implemented
> [-Wcpp]: => 1481:2
> + <stdin>: warning: #warning syscall io_uring_register not
> implemented [-Wcpp]: => 1484:2
> + <stdin>: warning: #warning syscall io_uring_setup not implemented
> [-Wcpp]: => 1478:2
>
> and more seem to be planned for this merge window.
>
> Shall each architcture maintainer take care of this hxxself, or will
> this be done in
> a coordinated way?
I was planning to send a patch for all architectures this time
(after all three sets are merged, which is now), and ask future
submitters to do it themselves when first adding a new system
call.
Arnd
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: New syscalls (was: Re: linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees))
2019-03-11 21:38 ` Arnd Bergmann
@ 2019-03-11 21:43 ` Christian Brauner
2019-03-12 8:31 ` Arnd Bergmann
0 siblings, 1 reply; 24+ messages in thread
From: Christian Brauner @ 2019-03-11 21:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Stephen Rothwell, Jens Axboe,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Linux Next Mailing List, Linux Kernel Mailing List, Linux-Arch
On Mon, Mar 11, 2019 at 10:38:07PM +0100, Arnd Bergmann wrote:
> On Mon, Mar 11, 2019 at 9:36 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Wed, Feb 13, 2019 at 3:22 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Wed, Feb 13, 2019 at 6:22 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > On Tue, 22 Jan 2019 14:10:27 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > > > 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.
> > > >
> > > > This is now a conflict between the block, tip and pidfd trees. The
> > > > resolution now looks like below.
> > >
> > > Checked it again, still looks good. Thanks,
> >
> > What's the plan with adding new syscalls to all architectures?
> >
> > + <stdin>: warning: #warning syscall io_uring_enter not implemented
> > [-Wcpp]: => 1481:2
> > + <stdin>: warning: #warning syscall io_uring_register not
> > implemented [-Wcpp]: => 1484:2
> > + <stdin>: warning: #warning syscall io_uring_setup not implemented
> > [-Wcpp]: => 1478:2
> >
> > and more seem to be planned for this merge window.
> >
> > Shall each architcture maintainer take care of this hxxself, or will
> > this be done in
> > a coordinated way?
>
> I was planning to send a patch for all architectures this time
> (after all three sets are merged, which is now), and ask future
Just to clarify, are you referring to your sets? I think Linus hasn't
gotten around to reviewing the PR for pidfd_send_signal() yet. :)
Christian
> submitters to do it themselves when first adding a new system
> call.
>
> Arnd
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: New syscalls (was: Re: linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees))
2019-03-11 21:43 ` Christian Brauner
@ 2019-03-12 8:31 ` Arnd Bergmann
2019-03-12 8:48 ` Christian Brauner
0 siblings, 1 reply; 24+ messages in thread
From: Arnd Bergmann @ 2019-03-12 8:31 UTC (permalink / raw)
To: Christian Brauner
Cc: Geert Uytterhoeven, Stephen Rothwell, Jens Axboe,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Linux Next Mailing List, Linux Kernel Mailing List, Linux-Arch
On Mon, Mar 11, 2019 at 10:43 PM Christian Brauner <christian@brauner.io> wrote:
> On Mon, Mar 11, 2019 at 10:38:07PM +0100, Arnd Bergmann wrote:
> > On Mon, Mar 11, 2019 at 9:36 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >
> > > Shall each architcture maintainer take care of this hxxself, or will
> > > this be done in
> > > a coordinated way?
> >
> > I was planning to send a patch for all architectures this time
> > (after all three sets are merged, which is now), and ask future
>
> Just to clarify, are you referring to your sets? I think Linus hasn't
> gotten around to reviewing the PR for pidfd_send_signal() yet. :)
Ah, I thought he had already merged both, the confusion was on
my end.
Arnd
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: New syscalls (was: Re: linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees))
2019-03-12 8:31 ` Arnd Bergmann
@ 2019-03-12 8:48 ` Christian Brauner
0 siblings, 0 replies; 24+ messages in thread
From: Christian Brauner @ 2019-03-12 8:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, Stephen Rothwell, Jens Axboe,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Linux Next Mailing List, Linux Kernel Mailing List, Linux-Arch
On March 12, 2019 9:31:33 AM GMT+01:00, Arnd Bergmann <arnd@arndb.de> wrote:
>On Mon, Mar 11, 2019 at 10:43 PM Christian Brauner
><christian@brauner.io> wrote:
>> On Mon, Mar 11, 2019 at 10:38:07PM +0100, Arnd Bergmann wrote:
>> > On Mon, Mar 11, 2019 at 9:36 AM Geert Uytterhoeven
><geert@linux-m68k.org> wrote:
>> > >
>> > > Shall each architcture maintainer take care of this hxxself, or
>will
>> > > this be done in
>> > > a coordinated way?
>> >
>> > I was planning to send a patch for all architectures this time
>> > (after all three sets are merged, which is now), and ask future
>>
>> Just to clarify, are you referring to your sets? I think Linus hasn't
>> gotten around to reviewing the PR for pidfd_send_signal() yet. :)
>
>Ah, I thought he had already merged both, the confusion was on
>my end.
I think I'll do a GIT PULL RESEND later today since I sent the original pr last Tuesday.
Christian
>
> Arnd
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-22 12:24 ` Christian Brauner
@ 2019-01-22 13:44 ` Arnd Bergmann
0 siblings, 0 replies; 24+ messages in thread
From: Arnd Bergmann @ 2019-01-22 13:44 UTC (permalink / raw)
To: Christian Brauner
Cc: Jens Axboe, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-22 11:46 ` Christian Brauner
@ 2019-01-22 12:24 ` Christian Brauner
2019-01-22 13:44 ` Arnd Bergmann
0 siblings, 1 reply; 24+ messages in thread
From: Christian Brauner @ 2019-01-22 12:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jens Axboe, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-22 11:42 ` Arnd Bergmann
@ 2019-01-22 11:46 ` Christian Brauner
2019-01-22 12:24 ` Christian Brauner
0 siblings, 1 reply; 24+ messages in thread
From: Christian Brauner @ 2019-01-22 11:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jens Axboe, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-22 10:57 ` Christian Brauner
@ 2019-01-22 11:42 ` Arnd Bergmann
2019-01-22 11:46 ` Christian Brauner
0 siblings, 1 reply; 24+ messages in thread
From: Arnd Bergmann @ 2019-01-22 11:42 UTC (permalink / raw)
To: Christian Brauner
Cc: Jens Axboe, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-22 10:48 ` Arnd Bergmann
@ 2019-01-22 10:57 ` Christian Brauner
2019-01-22 11:42 ` Arnd Bergmann
0 siblings, 1 reply; 24+ messages in thread
From: Christian Brauner @ 2019-01-22 10:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jens Axboe, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch
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
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-22 10:30 ` Christian Brauner
@ 2019-01-22 10:48 ` Arnd Bergmann
2019-01-22 10:57 ` Christian Brauner
0 siblings, 1 reply; 24+ messages in thread
From: Arnd Bergmann @ 2019-01-22 10:48 UTC (permalink / raw)
To: Christian Brauner
Cc: Jens Axboe, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-22 9:31 ` Christian Brauner
@ 2019-01-22 10:30 ` Christian Brauner
2019-01-22 10:48 ` Arnd Bergmann
0 siblings, 1 reply; 24+ messages in thread
From: Christian Brauner @ 2019-01-22 10:30 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jens Axboe, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-22 9:26 ` Arnd Bergmann
@ 2019-01-22 9:31 ` Christian Brauner
2019-01-22 10:30 ` Christian Brauner
0 siblings, 1 reply; 24+ messages in thread
From: Christian Brauner @ 2019-01-22 9:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jens Axboe, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-21 22:48 ` Christian Brauner
@ 2019-01-22 9:26 ` Arnd Bergmann
2019-01-22 9:31 ` Christian Brauner
0 siblings, 1 reply; 24+ messages in thread
From: Arnd Bergmann @ 2019-01-22 9:26 UTC (permalink / raw)
To: Christian Brauner
Cc: Jens Axboe, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-21 22:44 ` Jens Axboe
@ 2019-01-21 22:48 ` Christian Brauner
2019-01-22 9:26 ` Arnd Bergmann
0 siblings, 1 reply; 24+ messages in thread
From: Christian Brauner @ 2019-01-21 22:48 UTC (permalink / raw)
To: Jens Axboe
Cc: Arnd Bergmann, Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-21 20:23 ` Christian Brauner
@ 2019-01-21 22:44 ` Jens Axboe
2019-01-21 22:48 ` Christian Brauner
0 siblings, 1 reply; 24+ messages in thread
From: Jens Axboe @ 2019-01-21 22:44 UTC (permalink / raw)
To: Christian Brauner, Arnd Bergmann
Cc: Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-21 20:15 ` Arnd Bergmann
@ 2019-01-21 20:23 ` Christian Brauner
2019-01-21 22:44 ` Jens Axboe
0 siblings, 1 reply; 24+ messages in thread
From: Christian Brauner @ 2019-01-21 20:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch, Jens Axboe
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-21 19:13 ` Christian Brauner
@ 2019-01-21 20:15 ` Arnd Bergmann
2019-01-21 20:23 ` Christian Brauner
0 siblings, 1 reply; 24+ messages in thread
From: Arnd Bergmann @ 2019-01-21 20:15 UTC (permalink / raw)
To: Christian Brauner
Cc: Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, linux-arch, Jens Axboe
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-21 17:16 ` Arnd Bergmann
@ 2019-01-21 19:13 ` Christian Brauner
2019-01-21 20:15 ` Arnd Bergmann
0 siblings, 1 reply; 24+ messages in thread
From: Christian Brauner @ 2019-01-21 19:13 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Rothwell, Linux Next Mailing List, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: linux-next: manual merge of the pidfd tree with the y2038 tree
2019-01-21 3:39 linux-next: manual merge of the pidfd tree with the y2038 tree Stephen Rothwell
@ 2019-01-21 17:16 ` Arnd Bergmann
2019-01-21 19:13 ` Christian Brauner
0 siblings, 1 reply; 24+ messages in thread
From: Arnd Bergmann @ 2019-01-21 17:16 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Christian Brauner, Linux Next Mailing List, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* linux-next: manual merge of the pidfd tree with the y2038 tree
@ 2019-01-21 3:39 Stephen Rothwell
2019-01-21 17:16 ` Arnd Bergmann
0 siblings, 1 reply; 24+ messages in thread
From: Stephen Rothwell @ 2019-01-21 3:39 UTC (permalink / raw)
To: Christian Brauner, Arnd Bergmann
Cc: Linux Next Mailing List, Linux Kernel Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2019-03-12 8:48 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-22 3:10 linux-next: manual merge of the pidfd tree with the y2038 tree Stephen Rothwell
2019-02-13 5:22 ` linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees) Stephen Rothwell
2019-02-13 12:57 ` Arnd Bergmann
2019-03-11 8:36 ` New syscalls (was: Re: linux-next: manual merge of the pidfd tree with the y2038 tree (now block and tip trees)) Geert Uytterhoeven
2019-03-11 21:38 ` Arnd Bergmann
2019-03-11 21:43 ` Christian Brauner
2019-03-12 8:31 ` Arnd Bergmann
2019-03-12 8:48 ` Christian Brauner
-- strict thread matches above, loose matches on Subject: below --
2019-01-21 3:39 linux-next: manual merge of the pidfd tree with the y2038 tree Stephen Rothwell
2019-01-21 17:16 ` Arnd Bergmann
2019-01-21 19:13 ` Christian Brauner
2019-01-21 20:15 ` Arnd Bergmann
2019-01-21 20:23 ` Christian Brauner
2019-01-21 22:44 ` Jens Axboe
2019-01-21 22:48 ` Christian Brauner
2019-01-22 9:26 ` Arnd Bergmann
2019-01-22 9:31 ` Christian Brauner
2019-01-22 10:30 ` Christian Brauner
2019-01-22 10:48 ` Arnd Bergmann
2019-01-22 10:57 ` Christian Brauner
2019-01-22 11:42 ` Arnd Bergmann
2019-01-22 11:46 ` Christian Brauner
2019-01-22 12:24 ` Christian Brauner
2019-01-22 13:44 ` Arnd Bergmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).