Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230308073201.3102738-1-avagin@google.com> <20230308073201.3102738-5-avagin@google.com>
 <CALCETrUB_rCCBa9TPt+7x0MBfKP9L5e8JXva-rDzE3B-AGEzNA@mail.gmail.com>
In-Reply-To: <CALCETrUB_rCCBa9TPt+7x0MBfKP9L5e8JXva-rDzE3B-AGEzNA@mail.gmail.com>
From:   Andrei Vagin <avagin@gmail.com>
Date:   Sun, 9 Apr 2023 23:59:35 -0700
Message-ID: <CANaxB-wykCH+2fgrwBNe2BkTmEJpZjhsFBekiS_qaQHz4vYt8Q@mail.gmail.com>
Subject: Re: [PATCH 4/6] seccomp: add the synchronous mode for seccomp_unotify
To:     Andy Lutomirski <luto@kernel.org>
Cc:     Andrei Vagin <avagin@google.com>,
        Kees Cook <keescook@chromium.org>,
        Peter Zijlstra <peterz@infradead.org>,
        linux-kernel@vger.kernel.org,
        Christian Brauner <brauner@kernel.org>,
        Chen Yu <yu.c.chen@intel.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Ingo Molnar <mingo@redhat.com>,
        Juri Lelli <juri.lelli@redhat.com>,
        Peter Oskolkov <posk@google.com>,
        Tycho Andersen <tycho@tycho.pizza>,
        Will Drewry <wad@chromium.org>,
        Vincent Guittot <vincent.guittot@linaro.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, Apr 5, 2023 at 8:42=E2=80=AFPM Andy Lutomirski <luto@kernel.org> wr=
ote:
>
> On Tue, Mar 7, 2023 at 11:32=E2=80=AFPM Andrei Vagin <avagin@google.com> =
wrote:
> >
> > seccomp_unotify allows more privileged processes to do actions on behal=
f
> > of less privileged processes.
> >
> > In many cases, the workflow is fully synchronous. It means a target
> > process triggers a system call and passes controls to a supervisor
> > process that handles the system call and returns controls to the target
> > process. In this context, "synchronous" means that only one process is
> > running and another one is waiting.
> >
> > There is the WF_CURRENT_CPU flag that is used to advise the scheduler t=
o
> > move the wakee to the current CPU. For such synchronous workflows, it
> > makes context switches a few times faster.
> >
> > Right now, each interaction takes 12=C2=B5s. With this patch, it takes =
about
> > 3=C2=B5s.
>
> This is great, but:
>
> >
> > This change introduce the SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP flag that
> > it used to enable the sync mode.
>
> Other than being faster, what does this flag actually do in terms of
> user-visible semantics?

In short, the process handling an event wakes up on the same cpu where the
process that triggered the event has been running. Knowing this fact, the u=
ser
can understand when it is appropriate to use this flag.

Let's imagine that we have two processes where one calls syscalls (the
target) and another one handles these syscalls (the supervisor). In this ca=
se,
the user should see that both processes are running on the same cpu.

If we have one target process and one supervisor process, they synchronousl=
y
swap with each other and don't need to run on cpu concurrently.  But
it becomes more
complicated if one supervisor handles a group of target processes. In this
case, setting the SECCOMP_USER_NOTIF_FD_SYNC_WAKE_UP flag depends on the
frequency of events. If the supervisor often has pending events (doesn't sl=
eep
between events), it is better to unset the flag or add more supervisor
processes.

Thanks,
Andrei