From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Brauner Subject: Re: linux-next: manual merge of the pidfd tree with the y2038 tree Date: Tue, 22 Jan 2019 12:46:57 +0100 Message-ID: <20190122114656.joasjhlpwo3vy7hg@brauner.io> References: <20190121202328.rgrv54lybilsvitu@brauner.io> <20190121224811.gbvg22vg4kgg4kbs@brauner.io> <20190122093146.kmckcgdbvo2e7v3c@brauner.io> <20190122103009.vu2a67kviqhcb3cn@brauner.io> <20190122105747.6gxvghn7n5dxa65w@brauner.io> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Arnd Bergmann Cc: Jens Axboe , Stephen Rothwell , Linux Next Mailing List , Linux Kernel Mailing List , linux-arch List-Id: linux-arch.vger.kernel.org On Tue, Jan 22, 2019 at 12:42:44PM +0100, Arnd Bergmann wrote: > On Tue, Jan 22, 2019 at 11:57 AM Christian Brauner 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f67.google.com ([209.85.208.67]:39953 "EHLO mail-ed1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728254AbfAVLrB (ORCPT ); Tue, 22 Jan 2019 06:47:01 -0500 Received: by mail-ed1-f67.google.com with SMTP id g22so19032933edr.7 for ; Tue, 22 Jan 2019 03:46:59 -0800 (PST) Date: Tue, 22 Jan 2019 12:46:57 +0100 From: Christian Brauner Subject: Re: linux-next: manual merge of the pidfd tree with the y2038 tree Message-ID: <20190122114656.joasjhlpwo3vy7hg@brauner.io> References: <20190121202328.rgrv54lybilsvitu@brauner.io> <20190121224811.gbvg22vg4kgg4kbs@brauner.io> <20190122093146.kmckcgdbvo2e7v3c@brauner.io> <20190122103009.vu2a67kviqhcb3cn@brauner.io> <20190122105747.6gxvghn7n5dxa65w@brauner.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann Cc: Jens Axboe , Stephen Rothwell , Linux Next Mailing List , Linux Kernel Mailing List , linux-arch Message-ID: <20190122114657.NjhCuTlmScYyNoUba1mHDlzKydgpYuIyoey91K5YjTM@z> On Tue, Jan 22, 2019 at 12:42:44PM +0100, Arnd Bergmann wrote: > On Tue, Jan 22, 2019 at 11:57 AM Christian Brauner 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