lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 22 Jan 2019 12:46:57 +0100
From:   Christian Brauner <christian@...uner.io>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Jens Axboe <axboe@...nel.dk>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: linux-next: manual merge of the pidfd tree with the y2038 tree

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

Powered by blists - more mailing lists