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@xxxxxxxxxx> 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
