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 13:24:20 +0100 Message-ID: <20190122122419.b7lmm4j25w5cbmcx@brauner.io> References: <20190121202328.rgrv54lybilsvitu@brauner.io> <20190121224811.gbvg22vg4kgg4kbs@brauner.io> <20190122093146.kmckcgdbvo2e7v3c@brauner.io> <20190122103009.vu2a67kviqhcb3cn@brauner.io> <20190122105747.6gxvghn7n5dxa65w@brauner.io> <20190122114656.joasjhlpwo3vy7hg@brauner.io> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: <20190122114656.joasjhlpwo3vy7hg@brauner.io> 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: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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-f68.google.com ([209.85.208.68]:33854 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728198AbfAVMYY (ORCPT ); Tue, 22 Jan 2019 07:24:24 -0500 Received: by mail-ed1-f68.google.com with SMTP id b3so19231918ede.1 for ; Tue, 22 Jan 2019 04:24:22 -0800 (PST) Date: Tue, 22 Jan 2019 13:24:20 +0100 From: Christian Brauner Subject: Re: linux-next: manual merge of the pidfd tree with the y2038 tree Message-ID: <20190122122419.b7lmm4j25w5cbmcx@brauner.io> References: <20190121202328.rgrv54lybilsvitu@brauner.io> <20190121224811.gbvg22vg4kgg4kbs@brauner.io> <20190122093146.kmckcgdbvo2e7v3c@brauner.io> <20190122103009.vu2a67kviqhcb3cn@brauner.io> <20190122105747.6gxvghn7n5dxa65w@brauner.io> <20190122114656.joasjhlpwo3vy7hg@brauner.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190122114656.joasjhlpwo3vy7hg@brauner.io> 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: <20190122122420.eT5TZdR4LFWNzxPiBNOagWewS9i8jw31A-EAMpQoRTQ@z> 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 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