Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201127193238.821364-1-krisman@collabora.com>
In-Reply-To: <20201127193238.821364-1-krisman@collabora.com>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Tue, 1 Dec 2020 16:04:59 -0800
Message-ID: <CALCETrUh=+=3tYQQTC+Fsakx5xmzQmN_BfzQ7nwY=1GBwoGDNA@mail.gmail.com>
Subject: Re: [PATCH v8 0/7] Syscall User Dispatch
To:     Gabriel Krisman Bertazi <krisman@collabora.com>
Cc:     Andrew Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Kees Cook <keescook@chromium.org>,
        Paul Gofman <gofmanp@gmail.com>,
        Christian Brauner <christian.brauner@ubuntu.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Matthew Wilcox <willy@infradead.org>,
        Shuah Khan <shuah@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Linux API <linux-api@vger.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@vger.kernel.org>, X86 ML <x86@kernel.org>,
        kernel@collabora.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Nov 27, 2020 at 11:32 AM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Hi,
>
> This is v8 of syscall user dispatch.  Last version got some acks but
> there was one small documentation fix I wanted to do, as requested by
> Florian.  This also addresses the commit message fixup Peter requested.
>
> The only actual code change from v7 is solving a trivial merge conflict
> I myself created with the entry code fixup I made week and with
> something else in the TIP tree.
>
> I also shared this with glibc and there wasn't any complaints other than
> the matter about user-notif vs. siginfo, which was discussed in v7 and
> the understanding is that it is not necessary now and can be added
> later, if needed, on the same infrastructure without a new api.
>
> I'm not sure about TIP the rules, but is it too late to be queued for
> the next merge window?  I'd love to have this in 5.11 if possible, since
> it has been flying for quite a while.
>

Other than my little nitpick about on_syscall_dispatch(), the whole series is:

Reviewed-by: Andy Lutomirski <luto@kernel.org>