linux-next: manual merge of the block tree with the asm-generic tree

  Hi all,

Today's linux-next merge of the block tree got conflicts in:

  arch/alpha/kernel/syscalls/syscall.tbl
  arch/arm/tools/syscall.tbl
  arch/arm64/include/asm/unistd.h
  arch/arm64/include/asm/unistd32.h
  arch/m68k/kernel/syscalls/syscall.tbl
  arch/microblaze/kernel/syscalls/syscall.tbl
  arch/mips/kernel/syscalls/syscall_n32.tbl
  arch/mips/kernel/syscalls/syscall_n64.tbl
  arch/mips/kernel/syscalls/syscall_o32.tbl
  arch/parisc/kernel/syscalls/syscall.tbl
  arch/powerpc/kernel/syscalls/syscall.tbl
  arch/s390/kernel/syscalls/syscall.tbl
  arch/sh/kernel/syscalls/syscall.tbl
  arch/sparc/kernel/syscalls/syscall.tbl
  arch/x86/entry/syscalls/syscall_32.tbl
  arch/xtensa/kernel/syscalls/syscall.tbl
  include/uapi/asm-generic/unistd.h

between commits:

  2fd0ebad27bc ("arch: Reserve map_shadow_stack() syscall number for all architectures")

from the asm-generic tree and commits:

  9f6c532f59b2 ("futex: Add sys_futex_wake()")
  cb8c4312afca ("futex: Add sys_futex_wait()")
  0f4b5f972216 ("futex: Add sys_futex_requeue()")

from the block tree.

I fixed it up (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.
  

On Mon, Oct 09, 2023 at 12:31:18PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the block tree got conflicts in:
> 
>   arch/alpha/kernel/syscalls/syscall.tbl
>   arch/arm/tools/syscall.tbl
>   arch/arm64/include/asm/unistd.h
>   arch/arm64/include/asm/unistd32.h
>   arch/m68k/kernel/syscalls/syscall.tbl
>   arch/microblaze/kernel/syscalls/syscall.tbl
>   arch/mips/kernel/syscalls/syscall_n32.tbl
>   arch/mips/kernel/syscalls/syscall_n64.tbl
>   arch/mips/kernel/syscalls/syscall_o32.tbl
>   arch/parisc/kernel/syscalls/syscall.tbl
>   arch/powerpc/kernel/syscalls/syscall.tbl
>   arch/s390/kernel/syscalls/syscall.tbl
>   arch/sh/kernel/syscalls/syscall.tbl
>   arch/sparc/kernel/syscalls/syscall.tbl
>   arch/x86/entry/syscalls/syscall_32.tbl
>   arch/xtensa/kernel/syscalls/syscall.tbl
>   include/uapi/asm-generic/unistd.h
> 
> between commits:
> 
>   2fd0ebad27bc ("arch: Reserve map_shadow_stack() syscall number for all architectures")
> 
> from the asm-generic tree and commits:
> 
>   9f6c532f59b2 ("futex: Add sys_futex_wake()")
>   cb8c4312afca ("futex: Add sys_futex_wait()")
>   0f4b5f972216 ("futex: Add sys_futex_requeue()")
> 
> from the block tree.

fun fun fun..


> diff --cc arch/alpha/kernel/syscalls/syscall.tbl
> index 5d05ab716a74,b1865f9bb31e..000000000000
> --- a/arch/alpha/kernel/syscalls/syscall.tbl
> +++ b/arch/alpha/kernel/syscalls/syscall.tbl
> @@@ -492,4 -492,6 +492,7 @@@
>   560	common	set_mempolicy_home_node		sys_ni_syscall
>   561	common	cachestat			sys_cachestat
>   562	common	fchmodat2			sys_fchmodat2
>  -563	common	futex_wake			sys_futex_wake
>  -564	common	futex_wait			sys_futex_wait
>  -565	common	futex_requeue			sys_futex_requeue
>  +563	common	map_shadow_stack		sys_map_shadow_stack
> ++564	common	futex_wake			sys_futex_wake
> ++565	common	futex_wait			sys_futex_wait
> ++566	common	futex_requeue			sys_futex_requeue

So this renumbers the (futex) stuff on Alpha, does anybody care? AFAICT
Alpha does not follow the unistd order and meh.

> diff --cc include/uapi/asm-generic/unistd.h
> index 00df5af71ca1,d9e9cd13e577..000000000000
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@@ -822,12 -822,15 +822,18 @@@ __SYSCALL(__NR_cachestat, sys_cachestat
>   
>   #define __NR_fchmodat2 452
>   __SYSCALL(__NR_fchmodat2, sys_fchmodat2)
> + #define __NR_futex_wake 454
> + __SYSCALL(__NR_futex_wake, sys_futex_wake)
> + #define __NR_futex_wait 455
> + __SYSCALL(__NR_futex_wait, sys_futex_wait)
> + #define __NR_futex_requeue 456
> + __SYSCALL(__NR_futex_requeue, sys_futex_requeue)
>   
>  +#define __NR_map_shadow_stack 453
>  +__SYSCALL(__NR_map_shadow_stack, sys_map_shadow_stack)
>  +
>   #undef __NR_syscalls
> - #define __NR_syscalls 454
> + #define __NR_syscalls 457
>   
>   /*
>    * 32 bit systems traditionally used different

This seems to have the hunks in the wrong order, 453 should come before
454 no?
  

On Mon, Oct 9, 2023, at 10:48, Peter Zijlstra wrote:
> On Mon, Oct 09, 2023 at 12:31:18PM +1100, Stephen Rothwell wrote:
>> diff --cc arch/alpha/kernel/syscalls/syscall.tbl
>> index 5d05ab716a74,b1865f9bb31e..000000000000
>> --- a/arch/alpha/kernel/syscalls/syscall.tbl
>> +++ b/arch/alpha/kernel/syscalls/syscall.tbl
>> @@@ -492,4 -492,6 +492,7 @@@
>>   560	common	set_mempolicy_home_node		sys_ni_syscall
>>   561	common	cachestat			sys_cachestat
>>   562	common	fchmodat2			sys_fchmodat2
>>  -563	common	futex_wake			sys_futex_wake
>>  -564	common	futex_wait			sys_futex_wait
>>  -565	common	futex_requeue			sys_futex_requeue
>>  +563	common	map_shadow_stack		sys_map_shadow_stack
>> ++564	common	futex_wake			sys_futex_wake
>> ++565	common	futex_wait			sys_futex_wait
>> ++566	common	futex_requeue			sys_futex_requeue
>
> So this renumbers the (futex) stuff on Alpha, does anybody care? AFAICT
> Alpha does not follow the unistd order and meh.

Let's not make it worse for now. All the numbers since the
introduction of the time64 syscalls are offset by exactly 120
on alpha, and I'd prefer to keep it that way for the moment.

I still hope to eventually finish the conversion of all architectures
to a single syscall.tbl for numbers >400, and if that happens before
the end of alpha, a different ordering would just be extra pain.

    Arnd
  

Hi Peter,

On Mon, 9 Oct 2023 10:48:12 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
>
> >   #define __NR_fchmodat2 452
> >   __SYSCALL(__NR_fchmodat2, sys_fchmodat2)
> > + #define __NR_futex_wake 454
> > + __SYSCALL(__NR_futex_wake, sys_futex_wake)
> > + #define __NR_futex_wait 455
> > + __SYSCALL(__NR_futex_wait, sys_futex_wait)
> > + #define __NR_futex_requeue 456
> > + __SYSCALL(__NR_futex_requeue, sys_futex_requeue)
> >   
> >  +#define __NR_map_shadow_stack 453
> >  +__SYSCALL(__NR_map_shadow_stack, sys_map_shadow_stack)
> >  +
> >   #undef __NR_syscalls
> > - #define __NR_syscalls 454
> > + #define __NR_syscalls 457
> >   
> >   /*
> >    * 32 bit systems traditionally used different  
> 
> This seems to have the hunks in the wrong order, 453 should come before
> 454 no?

Oops, fixed thanks.
  

On Mon, Oct 09, 2023 at 11:00:19AM +0200, Arnd Bergmann wrote:
> On Mon, Oct 9, 2023, at 10:48, Peter Zijlstra wrote:
> > On Mon, Oct 09, 2023 at 12:31:18PM +1100, Stephen Rothwell wrote:
> >> diff --cc arch/alpha/kernel/syscalls/syscall.tbl
> >> index 5d05ab716a74,b1865f9bb31e..000000000000
> >> --- a/arch/alpha/kernel/syscalls/syscall.tbl
> >> +++ b/arch/alpha/kernel/syscalls/syscall.tbl
> >> @@@ -492,4 -492,6 +492,7 @@@
> >>   560	common	set_mempolicy_home_node		sys_ni_syscall
> >>   561	common	cachestat			sys_cachestat
> >>   562	common	fchmodat2			sys_fchmodat2
> >>  -563	common	futex_wake			sys_futex_wake
> >>  -564	common	futex_wait			sys_futex_wait
> >>  -565	common	futex_requeue			sys_futex_requeue
> >>  +563	common	map_shadow_stack		sys_map_shadow_stack
> >> ++564	common	futex_wake			sys_futex_wake
> >> ++565	common	futex_wait			sys_futex_wait
> >> ++566	common	futex_requeue			sys_futex_requeue
> >
> > So this renumbers the (futex) stuff on Alpha, does anybody care? AFAICT
> > Alpha does not follow the unistd order and meh.
> 
> Let's not make it worse for now. All the numbers since the
> introduction of the time64 syscalls are offset by exactly 120
> on alpha, and I'd prefer to keep it that way for the moment.
> 
> I still hope to eventually finish the conversion of all architectures
> to a single syscall.tbl for numbers >400, and if that happens before
> the end of alpha, a different ordering would just be extra pain.

Fair enough; should we look at rebase those futex patches for this? (bit
of a pain as that would also mean rebasing block)

Or do we want to keep this fixup in the merge resolution and make sure
Linus is aware?
  

On 10/9/23 8:13 AM, Peter Zijlstra wrote:
> On Mon, Oct 09, 2023 at 11:00:19AM +0200, Arnd Bergmann wrote:
>> On Mon, Oct 9, 2023, at 10:48, Peter Zijlstra wrote:
>>> On Mon, Oct 09, 2023 at 12:31:18PM +1100, Stephen Rothwell wrote:
>>>> diff --cc arch/alpha/kernel/syscalls/syscall.tbl
>>>> index 5d05ab716a74,b1865f9bb31e..000000000000
>>>> --- a/arch/alpha/kernel/syscalls/syscall.tbl
>>>> +++ b/arch/alpha/kernel/syscalls/syscall.tbl
>>>> @@@ -492,4 -492,6 +492,7 @@@
>>>>   560	common	set_mempolicy_home_node		sys_ni_syscall
>>>>   561	common	cachestat			sys_cachestat
>>>>   562	common	fchmodat2			sys_fchmodat2
>>>>  -563	common	futex_wake			sys_futex_wake
>>>>  -564	common	futex_wait			sys_futex_wait
>>>>  -565	common	futex_requeue			sys_futex_requeue
>>>>  +563	common	map_shadow_stack		sys_map_shadow_stack
>>>> ++564	common	futex_wake			sys_futex_wake
>>>> ++565	common	futex_wait			sys_futex_wait
>>>> ++566	common	futex_requeue			sys_futex_requeue
>>>
>>> So this renumbers the (futex) stuff on Alpha, does anybody care? AFAICT
>>> Alpha does not follow the unistd order and meh.
>>
>> Let's not make it worse for now. All the numbers since the
>> introduction of the time64 syscalls are offset by exactly 120
>> on alpha, and I'd prefer to keep it that way for the moment.
>>
>> I still hope to eventually finish the conversion of all architectures
>> to a single syscall.tbl for numbers >400, and if that happens before
>> the end of alpha, a different ordering would just be extra pain.
> 
> Fair enough; should we look at rebase those futex patches for this? (bit
> of a pain as that would also mean rebasing block)

From my point of view, this isn't a huge problem if we do it now. The
io_uring-futex branch is a separate branch and I have nothing on top of
it, so I could easily just re-pull your updated branch and rebase my
changes on top.

> Or do we want to keep this fixup in the merge resolution and make sure
> Linus is aware?

If you're OK with it, I'd say let's rebase and save ourselves the
trouble at merge time.
  

On Mon, Oct 9, 2023, at 16:16, Jens Axboe wrote:
> On 10/9/23 8:13 AM, Peter Zijlstra wrote:
>> On Mon, Oct 09, 2023 at 11:00:19AM +0200, Arnd Bergmann wrote:
>>>
>>> Let's not make it worse for now. All the numbers since the
>>> introduction of the time64 syscalls are offset by exactly 120
>>> on alpha, and I'd prefer to keep it that way for the moment.
>>>
>>> I still hope to eventually finish the conversion of all architectures
>>> to a single syscall.tbl for numbers >400, and if that happens before
>>> the end of alpha, a different ordering would just be extra pain.
>> 
>> Fair enough; should we look at rebase those futex patches for this? (bit
>> of a pain as that would also mean rebasing block)
>
> From my point of view, this isn't a huge problem if we do it now. The
> io_uring-futex branch is a separate branch and I have nothing on top of
> it, so I could easily just re-pull your updated branch and rebase my
> changes on top.
>
>> Or do we want to keep this fixup in the merge resolution and make sure
>> Linus is aware?
>
> If you're OK with it, I'd say let's rebase and save ourselves the
> trouble at merge time.

Sounds good, thanks.

If it's any help, I can also merge the patches that wire up the
syscalls through the asm-generic tree to avoid the conflicts
altogether.

     Arnd
  

On 10/9/23 8:16 AM, Jens Axboe wrote:
> On 10/9/23 8:13 AM, Peter Zijlstra wrote:
>> On Mon, Oct 09, 2023 at 11:00:19AM +0200, Arnd Bergmann wrote:
>>> On Mon, Oct 9, 2023, at 10:48, Peter Zijlstra wrote:
>>>> On Mon, Oct 09, 2023 at 12:31:18PM +1100, Stephen Rothwell wrote:
>>>>> diff --cc arch/alpha/kernel/syscalls/syscall.tbl
>>>>> index 5d05ab716a74,b1865f9bb31e..000000000000
>>>>> --- a/arch/alpha/kernel/syscalls/syscall.tbl
>>>>> +++ b/arch/alpha/kernel/syscalls/syscall.tbl
>>>>> @@@ -492,4 -492,6 +492,7 @@@
>>>>>   560	common	set_mempolicy_home_node		sys_ni_syscall
>>>>>   561	common	cachestat			sys_cachestat
>>>>>   562	common	fchmodat2			sys_fchmodat2
>>>>>  -563	common	futex_wake			sys_futex_wake
>>>>>  -564	common	futex_wait			sys_futex_wait
>>>>>  -565	common	futex_requeue			sys_futex_requeue
>>>>>  +563	common	map_shadow_stack		sys_map_shadow_stack
>>>>> ++564	common	futex_wake			sys_futex_wake
>>>>> ++565	common	futex_wait			sys_futex_wait
>>>>> ++566	common	futex_requeue			sys_futex_requeue
>>>>
>>>> So this renumbers the (futex) stuff on Alpha, does anybody care? AFAICT
>>>> Alpha does not follow the unistd order and meh.
>>>
>>> Let's not make it worse for now. All the numbers since the
>>> introduction of the time64 syscalls are offset by exactly 120
>>> on alpha, and I'd prefer to keep it that way for the moment.
>>>
>>> I still hope to eventually finish the conversion of all architectures
>>> to a single syscall.tbl for numbers >400, and if that happens before
>>> the end of alpha, a different ordering would just be extra pain.
>>
>> Fair enough; should we look at rebase those futex patches for this? (bit
>> of a pain as that would also mean rebasing block)
> 
> From my point of view, this isn't a huge problem if we do it now. The
> io_uring-futex branch is a separate branch and I have nothing on top of
> it, so I could easily just re-pull your updated branch and rebase my
> changes on top.
> 
>> Or do we want to keep this fixup in the merge resolution and make sure
>> Linus is aware?
> 
> If you're OK with it, I'd say let's rebase and save ourselves the
> trouble at merge time.

Peter, what's the verdict - do you want to rebase it, or leave it as-is?
  

On Wed, Oct 11, 2023 at 10:21:06AM -0600, Jens Axboe wrote:
> On 10/9/23 8:16 AM, Jens Axboe wrote:
> > On 10/9/23 8:13 AM, Peter Zijlstra wrote:
> >> On Mon, Oct 09, 2023 at 11:00:19AM +0200, Arnd Bergmann wrote:
> >>> On Mon, Oct 9, 2023, at 10:48, Peter Zijlstra wrote:
> >>>> On Mon, Oct 09, 2023 at 12:31:18PM +1100, Stephen Rothwell wrote:
> >>>>> diff --cc arch/alpha/kernel/syscalls/syscall.tbl
> >>>>> index 5d05ab716a74,b1865f9bb31e..000000000000
> >>>>> --- a/arch/alpha/kernel/syscalls/syscall.tbl
> >>>>> +++ b/arch/alpha/kernel/syscalls/syscall.tbl
> >>>>> @@@ -492,4 -492,6 +492,7 @@@
> >>>>>   560	common	set_mempolicy_home_node		sys_ni_syscall
> >>>>>   561	common	cachestat			sys_cachestat
> >>>>>   562	common	fchmodat2			sys_fchmodat2
> >>>>>  -563	common	futex_wake			sys_futex_wake
> >>>>>  -564	common	futex_wait			sys_futex_wait
> >>>>>  -565	common	futex_requeue			sys_futex_requeue
> >>>>>  +563	common	map_shadow_stack		sys_map_shadow_stack
> >>>>> ++564	common	futex_wake			sys_futex_wake
> >>>>> ++565	common	futex_wait			sys_futex_wait
> >>>>> ++566	common	futex_requeue			sys_futex_requeue
> >>>>
> >>>> So this renumbers the (futex) stuff on Alpha, does anybody care? AFAICT
> >>>> Alpha does not follow the unistd order and meh.
> >>>
> >>> Let's not make it worse for now. All the numbers since the
> >>> introduction of the time64 syscalls are offset by exactly 120
> >>> on alpha, and I'd prefer to keep it that way for the moment.
> >>>
> >>> I still hope to eventually finish the conversion of all architectures
> >>> to a single syscall.tbl for numbers >400, and if that happens before
> >>> the end of alpha, a different ordering would just be extra pain.
> >>
> >> Fair enough; should we look at rebase those futex patches for this? (bit
> >> of a pain as that would also mean rebasing block)
> > 
> > From my point of view, this isn't a huge problem if we do it now. The
> > io_uring-futex branch is a separate branch and I have nothing on top of
> > it, so I could easily just re-pull your updated branch and rebase my
> > changes on top.
> > 
> >> Or do we want to keep this fixup in the merge resolution and make sure
> >> Linus is aware?
> > 
> > If you're OK with it, I'd say let's rebase and save ourselves the
> > trouble at merge time.
> 
> Peter, what's the verdict - do you want to rebase it, or leave it as-is?

Ah, I looked into doing this, but tip/locking/core has since grown a
bunch of patches and has a merge commit -- I talked to Ingo yesterday
and he proposed just queueing a fix on top instead of doing a full
rebase.

Ingo, that still your preferred solution?
  

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, Oct 11, 2023 at 10:21:06AM -0600, Jens Axboe wrote:
> > On 10/9/23 8:16 AM, Jens Axboe wrote:
> > > On 10/9/23 8:13 AM, Peter Zijlstra wrote:
> > >> On Mon, Oct 09, 2023 at 11:00:19AM +0200, Arnd Bergmann wrote:
> > >>> On Mon, Oct 9, 2023, at 10:48, Peter Zijlstra wrote:
> > >>>> On Mon, Oct 09, 2023 at 12:31:18PM +1100, Stephen Rothwell wrote:
> > >>>>> diff --cc arch/alpha/kernel/syscalls/syscall.tbl
> > >>>>> index 5d05ab716a74,b1865f9bb31e..000000000000
> > >>>>> --- a/arch/alpha/kernel/syscalls/syscall.tbl
> > >>>>> +++ b/arch/alpha/kernel/syscalls/syscall.tbl
> > >>>>> @@@ -492,4 -492,6 +492,7 @@@
> > >>>>>   560	common	set_mempolicy_home_node		sys_ni_syscall
> > >>>>>   561	common	cachestat			sys_cachestat
> > >>>>>   562	common	fchmodat2			sys_fchmodat2
> > >>>>>  -563	common	futex_wake			sys_futex_wake
> > >>>>>  -564	common	futex_wait			sys_futex_wait
> > >>>>>  -565	common	futex_requeue			sys_futex_requeue
> > >>>>>  +563	common	map_shadow_stack		sys_map_shadow_stack
> > >>>>> ++564	common	futex_wake			sys_futex_wake
> > >>>>> ++565	common	futex_wait			sys_futex_wait
> > >>>>> ++566	common	futex_requeue			sys_futex_requeue
> > >>>>
> > >>>> So this renumbers the (futex) stuff on Alpha, does anybody care? AFAICT
> > >>>> Alpha does not follow the unistd order and meh.
> > >>>
> > >>> Let's not make it worse for now. All the numbers since the
> > >>> introduction of the time64 syscalls are offset by exactly 120
> > >>> on alpha, and I'd prefer to keep it that way for the moment.
> > >>>
> > >>> I still hope to eventually finish the conversion of all architectures
> > >>> to a single syscall.tbl for numbers >400, and if that happens before
> > >>> the end of alpha, a different ordering would just be extra pain.
> > >>
> > >> Fair enough; should we look at rebase those futex patches for this? (bit
> > >> of a pain as that would also mean rebasing block)
> > > 
> > > From my point of view, this isn't a huge problem if we do it now. The
> > > io_uring-futex branch is a separate branch and I have nothing on top of
> > > it, so I could easily just re-pull your updated branch and rebase my
> > > changes on top.
> > > 
> > >> Or do we want to keep this fixup in the merge resolution and make sure
> > >> Linus is aware?
> > > 
> > > If you're OK with it, I'd say let's rebase and save ourselves the
> > > trouble at merge time.
> > 
> > Peter, what's the verdict - do you want to rebase it, or leave it as-is?
> 
> Ah, I looked into doing this, but tip/locking/core has since grown a
> bunch of patches and has a merge commit -- I talked to Ingo yesterday
> and he proposed just queueing a fix on top instead of doing a full
> rebase.
> 
> Ingo, that still your preferred solution?

Yeah, that would be the best solution IMO - it's not like there's any real 
prospect of someone bisecting futex2 patch-enablement commits on Alpha ... 
and the bisection distance isn't particularly large either in any case.

[ This would also document the very real historic conflict between these 
  numbers, as it happened. ]

Thanks,

	Ingo
  

On 10/11/23 3:32 PM, Ingo Molnar wrote:
> 
> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
>> On Wed, Oct 11, 2023 at 10:21:06AM -0600, Jens Axboe wrote:
>>> On 10/9/23 8:16 AM, Jens Axboe wrote:
>>>> On 10/9/23 8:13 AM, Peter Zijlstra wrote:
>>>>> On Mon, Oct 09, 2023 at 11:00:19AM +0200, Arnd Bergmann wrote:
>>>>>> On Mon, Oct 9, 2023, at 10:48, Peter Zijlstra wrote:
>>>>>>> On Mon, Oct 09, 2023 at 12:31:18PM +1100, Stephen Rothwell wrote:
>>>>>>>> diff --cc arch/alpha/kernel/syscalls/syscall.tbl
>>>>>>>> index 5d05ab716a74,b1865f9bb31e..000000000000
>>>>>>>> --- a/arch/alpha/kernel/syscalls/syscall.tbl
>>>>>>>> +++ b/arch/alpha/kernel/syscalls/syscall.tbl
>>>>>>>> @@@ -492,4 -492,6 +492,7 @@@
>>>>>>>>   560	common	set_mempolicy_home_node		sys_ni_syscall
>>>>>>>>   561	common	cachestat			sys_cachestat
>>>>>>>>   562	common	fchmodat2			sys_fchmodat2
>>>>>>>>  -563	common	futex_wake			sys_futex_wake
>>>>>>>>  -564	common	futex_wait			sys_futex_wait
>>>>>>>>  -565	common	futex_requeue			sys_futex_requeue
>>>>>>>>  +563	common	map_shadow_stack		sys_map_shadow_stack
>>>>>>>> ++564	common	futex_wake			sys_futex_wake
>>>>>>>> ++565	common	futex_wait			sys_futex_wait
>>>>>>>> ++566	common	futex_requeue			sys_futex_requeue
>>>>>>>
>>>>>>> So this renumbers the (futex) stuff on Alpha, does anybody care? AFAICT
>>>>>>> Alpha does not follow the unistd order and meh.
>>>>>>
>>>>>> Let's not make it worse for now. All the numbers since the
>>>>>> introduction of the time64 syscalls are offset by exactly 120
>>>>>> on alpha, and I'd prefer to keep it that way for the moment.
>>>>>>
>>>>>> I still hope to eventually finish the conversion of all architectures
>>>>>> to a single syscall.tbl for numbers >400, and if that happens before
>>>>>> the end of alpha, a different ordering would just be extra pain.
>>>>>
>>>>> Fair enough; should we look at rebase those futex patches for this? (bit
>>>>> of a pain as that would also mean rebasing block)
>>>>
>>>> From my point of view, this isn't a huge problem if we do it now. The
>>>> io_uring-futex branch is a separate branch and I have nothing on top of
>>>> it, so I could easily just re-pull your updated branch and rebase my
>>>> changes on top.
>>>>
>>>>> Or do we want to keep this fixup in the merge resolution and make sure
>>>>> Linus is aware?
>>>>
>>>> If you're OK with it, I'd say let's rebase and save ourselves the
>>>> trouble at merge time.
>>>
>>> Peter, what's the verdict - do you want to rebase it, or leave it as-is?
>>
>> Ah, I looked into doing this, but tip/locking/core has since grown a
>> bunch of patches and has a merge commit -- I talked to Ingo yesterday
>> and he proposed just queueing a fix on top instead of doing a full
>> rebase.
>>
>> Ingo, that still your preferred solution?
> 
> Yeah, that would be the best solution IMO - it's not like there's any real 
> prospect of someone bisecting futex2 patch-enablement commits on Alpha ... 
> and the bisection distance isn't particularly large either in any case.

OK, works for me. I'll keep my branch as-is, and just ensure it gets
sent out after locking/core has been pulled by Linus.
  

* Jens Axboe <axboe@kernel.dk> wrote:

> >>> Peter, what's the verdict - do you want to rebase it, or leave it 
> >>> as-is?
> >>
> >> Ah, I looked into doing this, but tip/locking/core has since grown a 
> >> bunch of patches and has a merge commit -- I talked to Ingo yesterday 
> >> and he proposed just queueing a fix on top instead of doing a full 
> >> rebase.
> >>
> >> Ingo, that still your preferred solution?
> > 
> > Yeah, that would be the best solution IMO - it's not like there's any 
> > real prospect of someone bisecting futex2 patch-enablement commits on 
> > Alpha ... and the bisection distance isn't particularly large either in 
> > any case.
> 
> OK, works for me. I'll keep my branch as-is, and just ensure it gets sent 
> out after locking/core has been pulled by Linus.

Thank you!

	Ingo
  

* Ingo Molnar <mingo@kernel.org> wrote:

> 
> * Jens Axboe <axboe@kernel.dk> wrote:
> 
> > >>> Peter, what's the verdict - do you want to rebase it, or leave it 
> > >>> as-is?
> > >>
> > >> Ah, I looked into doing this, but tip/locking/core has since grown a 
> > >> bunch of patches and has a merge commit -- I talked to Ingo yesterday 
> > >> and he proposed just queueing a fix on top instead of doing a full 
> > >> rebase.
> > >>
> > >> Ingo, that still your preferred solution?
> > > 
> > > Yeah, that would be the best solution IMO - it's not like there's any 
> > > real prospect of someone bisecting futex2 patch-enablement commits on 
> > > Alpha ... and the bisection distance isn't particularly large either in 
> > > any case.
> > 
> > OK, works for me. I'll keep my branch as-is, and just ensure it gets sent 
> > out after locking/core has been pulled by Linus.
> 
> Thank you!

Heads-up: the futex syscall numbers are now fixed on Alpha in the locking 
tree via:

  dcc134510eef ("alpha: Fix up new futex syscall numbers")

This would, I presume, trigger a new conflict in -next, which should be 
resolved in an identical fashion.

Jens, feel free to send your tree to Linus in any ordering with the
locking tree, there's no real dependency between them, and whoever
sends last should warn Linus about the known conflict.

Thanks,

	Ingo
  

Hi Ingo,

On Mon, 16 Oct 2023 13:53:13 +0200 Ingo Molnar <mingo@kernel.org> wrote:
>
> Heads-up: the futex syscall numbers are now fixed on Alpha in the locking 
> tree via:
> 
>   dcc134510eef ("alpha: Fix up new futex syscall numbers")

Thanks.

> This would, I presume, trigger a new conflict in -next, which should be 
> resolved in an identical fashion.

Indeed, done.
  

Hi all,

On Mon, 9 Oct 2023 12:31:18 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the block tree got conflicts in:
> 
>   arch/alpha/kernel/syscalls/syscall.tbl
>   arch/arm/tools/syscall.tbl
>   arch/arm64/include/asm/unistd.h
>   arch/arm64/include/asm/unistd32.h
>   arch/m68k/kernel/syscalls/syscall.tbl
>   arch/microblaze/kernel/syscalls/syscall.tbl
>   arch/mips/kernel/syscalls/syscall_n32.tbl
>   arch/mips/kernel/syscalls/syscall_n64.tbl
>   arch/mips/kernel/syscalls/syscall_o32.tbl
>   arch/parisc/kernel/syscalls/syscall.tbl
>   arch/powerpc/kernel/syscalls/syscall.tbl
>   arch/s390/kernel/syscalls/syscall.tbl
>   arch/sh/kernel/syscalls/syscall.tbl
>   arch/sparc/kernel/syscalls/syscall.tbl
>   arch/x86/entry/syscalls/syscall_32.tbl
>   arch/xtensa/kernel/syscalls/syscall.tbl
>   include/uapi/asm-generic/unistd.h
> 
> between commits:
> 
>   2fd0ebad27bc ("arch: Reserve map_shadow_stack() syscall number for all architectures")
> 
> from the asm-generic tree and commits:
> 
>   9f6c532f59b2 ("futex: Add sys_futex_wake()")
>   cb8c4312afca ("futex: Add sys_futex_wait()")
>   0f4b5f972216 ("futex: Add sys_futex_requeue()")
> 
> from the block tree.

This is now a conflict between the asm-generic tree and Linus' tree.