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

[Christian Brauner]

On Tue, Jan 22, 2019 at 10:26:56AM +0100, Arnd Bergmann wrote:
> On Mon, Jan 21, 2019 at 11:48 PM Christian Brauner <christian@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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