linux-kernel - Re: linux-next: manual merge of the pidfd tree with the y2038 tree

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 linux-hardening linux-cve-announce 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]

Message-ID: <CAK8P3a0HJX6+1vks=ZCqNymLwWFS+Wt5PPuYnLedpMo=aVSwKA@mail.gmail.com>
Date:   Tue, 22 Jan 2019 12:42:44 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Christian Brauner <christian@...uner.io>
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 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.

      Arnd