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

[Christian Brauner]

On Tue, Jan 22, 2019 at 12:46:56PM +0100, Christian Brauner wrote:
> On Tue, Jan 22, 2019 at 12:42:44PM +0100, Arnd Bergmann wrote:
> > On Tue, Jan 22, 2019 at 11:57 AM Christian Brauner <christian@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