linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ 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; 8+ 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] 8+ messages in thread

end of thread, other threads:[~2019-03-12  8:48 UTC | newest]

Thread overview: 8+ 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

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