Message ID | 20231009123118.4487a0e1@canb.auug.org.au |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a888:0:b0:403:3b70:6f57 with SMTP id x8csp1611151vqo; Sun, 8 Oct 2023 19:06:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGEZc4mEEGvmrgDLyUJG2y3LbKouYWrUvqnA5SKS4kmi6w+Xahvb44jcUIZoGs11L/LlTRm X-Received: by 2002:a05:6830:33b7:b0:6bd:b879:c313 with SMTP id dw23-20020a05683033b700b006bdb879c313mr13618669otb.10.1696817189422; Sun, 08 Oct 2023 19:06:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696817189; cv=none; d=google.com; s=arc-20160816; b=mpiEMZdel7DerMiGMOcXvaHlFJ+94pMFvB/6mw1gK2aCFlHOwwE7wTEEhzLafWgwuK Thn+JTi6H5balDkdJepZ/msvdNv9w9/kKnSTRVBBsntEroaDuA4XR9aNZTJvwl/p6dWb m3S5lBVmAEVAQWk764zYKKRoczhOTuiE2G0Tq6FcQWGHGy7FnySc+qDRtv5lg67p0uVg wyJ+SHtLPve4vcboj5XsByGWQJ0cSrce9wA0I+agtvEpK8DKOppgxf9qCdIEWcsLZ2aZ t42S6mAtDiwhQeHzq+KvsaE/iXKHkcxKeqfwRITjiUtQURrkzv8n6VOv7RMQ/V/0Crd0 q5Yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=RF58q+xXgFqMy1W+kf6f5efUO8YDOhVnUo6mzSypuPA=; fh=D8L+r+GBd0IUgrJR9+oPitlOw94f+chq6tksXt86uYs=; b=OzsWe72C3r7eAyGNGQEBrnEBzVi6ML7TGChjzwCkkaC/8lACczBlMVStpizc0BWeuI GYofdQUpdnV7QNAOfYqW29Pys771+wJCJ+mRJPJ7qUHaboI9tgkl+XkvE+hxhq44WCXK 8sYf06vzXjz4V2BUTaN0PYH0FGXaHbXoLduLFgrJVRtTULMqt5SbtBWlSLqw469obqLv pluxj2zQ+2GiORPfEVDwfPa7YdvmdZkYDMbe8BuTme5vzEPm4TZNOg89jgUQKqVE1b4u 6X0EbgYvgc4uIP7owfBcIbqhDbk53deEcJXArHAJjvyNhlJVESF+3nY47iiQ1KpNuo9Q TttQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b=gEOc2+2P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canb.auug.org.au Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id d24-20020a634f18000000b00577a519621bsi8219403pgb.231.2023.10.08.19.06.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Oct 2023 19:06:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@canb.auug.org.au header.s=201702 header.b=gEOc2+2P; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=canb.auug.org.au Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 8A216802D1A7; Sun, 8 Oct 2023 19:06:26 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344847AbjJIBb3 (ORCPT <rfc822;ezelljr.billy@gmail.com> + 19 others); Sun, 8 Oct 2023 21:31:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33512 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232267AbjJIBb1 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 8 Oct 2023 21:31:27 -0400 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4101799; Sun, 8 Oct 2023 18:31:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canb.auug.org.au; s=201702; t=1696815083; bh=RF58q+xXgFqMy1W+kf6f5efUO8YDOhVnUo6mzSypuPA=; h=Date:From:To:Cc:Subject:From; b=gEOc2+2PSwcdFd9tQ5V9fn/DDOwyYub5ThVajV3WkX3YFpbh+Rm9N5rNyTvX0olB2 2x2V4U/02u1iaJj5X3JkQTxnrfzpJXL8u017SvSxwxaSPnO9TN7n4CORz9UhKp4eep rQoWNLGOspz6WlyxLFI1/8yvDlrj3+2AkeGEvLlUt1YPWcRQyZDyFavGqZnDCGMxda RRsiVTdhXkphpaVAMAl5v1ESE9QPx0muS4OWQLVkcicXUUgT6z0Ep9gp74fR0CV9Yr MmGLFHWL8eKhlyyP5S7J524qVXXXsKYbirUO4+scEzgnFOeVflf2nvqeoudA0/iXVi j0S8dNU8cpCtQ== Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4S3hMG4fTQz4x5q; Mon, 9 Oct 2023 12:31:20 +1100 (AEDT) Date: Mon, 9 Oct 2023 12:31:18 +1100 From: Stephen Rothwell <sfr@canb.auug.org.au> To: Jens Axboe <axboe@kernel.dk>, Arnd Bergmann <arnd@arndb.de> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linux Next Mailing List <linux-next@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, Sohil Mehta <sohil.mehta@intel.com> Subject: linux-next: manual merge of the block tree with the asm-generic tree Message-ID: <20231009123118.4487a0e1@canb.auug.org.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/teycTZNgREgDu/GHd9yJThK"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Spam-Status: No, score=2.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Sun, 08 Oct 2023 19:06:26 -0700 (PDT) X-Spam-Level: ** X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779241781482453761 X-GMAIL-MSGID: 1779241781482453761 |
Series |
linux-next: manual merge of the block tree with the asm-generic tree
|
|
Commit Message
Stephen Rothwell
Oct. 9, 2023, 1:31 a.m. UTC
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.
Comments
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.
diff --cc arch/alpha/kernel/syscalls/syscall.tbl index 5d05ab716a74,b1865f9bb31e..000000000000 --- a/arch/alpha/kernel/syscalls/syscall.tbl diff --cc arch/arm/tools/syscall.tbl index 45ec6e1dc872,93d0d46cbb15..000000000000 --- a/arch/arm/tools/syscall.tbl diff --cc arch/arm64/include/asm/unistd.h index 6a28fb91b85d,531effca5f1f..000000000000 --- a/arch/arm64/include/asm/unistd.h diff --cc arch/m68k/kernel/syscalls/syscall.tbl index 12d0ce43b094,f7f997a88bab..000000000000 --- a/arch/m68k/kernel/syscalls/syscall.tbl diff --cc arch/microblaze/kernel/syscalls/syscall.tbl index de8219c4300c,2967ec26b978..000000000000 --- a/arch/microblaze/kernel/syscalls/syscall.tbl diff --cc arch/mips/kernel/syscalls/syscall_n32.tbl index a5096a064fb4,383abb1713f4..000000000000 --- a/arch/mips/kernel/syscalls/syscall_n32.tbl diff --cc arch/mips/kernel/syscalls/syscall_n64.tbl index 0044031d9c70,c9bd09ba905f..000000000000 --- a/arch/mips/kernel/syscalls/syscall_n64.tbl diff --cc arch/mips/kernel/syscalls/syscall_o32.tbl index cf44a6ac38fa,ba5ef6cea97a..000000000000 --- a/arch/mips/kernel/syscalls/syscall_o32.tbl diff --cc arch/parisc/kernel/syscalls/syscall.tbl index 4048ed480a04,9f0f6df55361..000000000000 --- a/arch/parisc/kernel/syscalls/syscall.tbl diff --cc arch/powerpc/kernel/syscalls/syscall.tbl index d845e14c38f3,26fc41904266..000000000000 --- a/arch/powerpc/kernel/syscalls/syscall.tbl diff --cc arch/s390/kernel/syscalls/syscall.tbl index 416645f1c1fb,31be90b241f7..000000000000 --- a/arch/s390/kernel/syscalls/syscall.tbl diff --cc arch/sh/kernel/syscalls/syscall.tbl index bf36587b87b5,4bc5d488ab17..000000000000 --- a/arch/sh/kernel/syscalls/syscall.tbl diff --cc arch/sparc/kernel/syscalls/syscall.tbl index f45f8c5ed076,8404c8e50394..000000000000 --- a/arch/sparc/kernel/syscalls/syscall.tbl diff --cc arch/x86/entry/syscalls/syscall_32.tbl index 54748f6d7c45,31c48bc2c3d8..000000000000 --- a/arch/x86/entry/syscalls/syscall_32.tbl diff --cc arch/xtensa/kernel/syscalls/syscall.tbl index 10a7eecbedf0,dd71ecce8b86..000000000000 --- a/arch/xtensa/kernel/syscalls/syscall.tbl diff --cc include/uapi/asm-generic/unistd.h index 00df5af71ca1,d9e9cd13e577..000000000000 --- a/include/uapi/asm-generic/unistd.h