[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a3Mf_+-MY5kdeY7sqwUgCUi=PksWz1pGDy+o0ZfgF93Zw@mail.gmail.com>
Date: Wed, 8 Jul 2020 09:47:33 +0200
From: Arnd Bergmann <arnd@...db.de>
To: Mickaël Salaün <mic@...ikod.net>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Andy Lutomirski <luto@...capital.net>,
Anton Ivanov <anton.ivanov@...bridgegreys.com>,
Casey Schaufler <casey@...aufler-ca.com>,
James Morris <jmorris@...ei.org>, Jann Horn <jannh@...gle.com>,
Jeff Dike <jdike@...toit.com>,
Jonathan Corbet <corbet@....net>,
Kees Cook <keescook@...omium.org>,
Michael Kerrisk <mtk.manpages@...il.com>,
Mickaël Salaün <mickael.salaun@....gouv.fr>,
Richard Weinberger <richard@....at>,
"Serge E . Hallyn" <serge@...lyn.com>,
Shuah Khan <shuah@...nel.org>,
Vincent Dagonneau <vincent.dagonneau@....gouv.fr>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
Linux API <linux-api@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>,
"open list:KERNEL SELFTEST FRAMEWORK"
<linux-kselftest@...r.kernel.org>,
LSM List <linux-security-module@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [PATCH v19 09/12] arch: Wire up landlock() syscall
On Wed, Jul 8, 2020 at 9:31 AM Mickaël Salaün <mic@...ikod.net> wrote:
> On 08/07/2020 09:22, Arnd Bergmann wrote:
> > On Tue, Jul 7, 2020 at 8:10 PM Mickaël Salaün <mic@...ikod.net> wrote:
> >
> >> index f4a01305d9a6..a63a411a74d5 100644
> >> --- a/include/uapi/asm-generic/unistd.h
> >> +++ b/include/uapi/asm-generic/unistd.h
>
> OK, I'll rebase the next series on linux-next.
Just change the number to the next free one, without actually rebasing.
It's always a bit messy to have multiple syscalls added, but I think that
causes the least confusion.
> Do you know if there is other syscalls on their way to linux-next?
None that I'm aware of.
> Are the other parts of arch/syscall OK for you?
The arch/* and include/uapi/asm-generic changes look ok to me.
I'll reply to the syscall implementation separately/
Arnd
Powered by blists - more mailing lists