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

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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

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

[Christian Brauner]

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

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

[Christian Brauner]

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

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

[Jens Axboe]

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

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

[Jens Axboe]

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

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

[Christian Brauner]

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.

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

[Christian Brauner]

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.

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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

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

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

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

[Christian Brauner]

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

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

[Christian Brauner]

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

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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

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

[Christian Brauner]

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

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

[Christian Brauner]

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

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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

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

[Christian Brauner]

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

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

[Christian Brauner]

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

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

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

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

[Arnd Bergmann]

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

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

[Arnd Bergmann]

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