Messages in this thread | | | From | Andrei Vagin <> | Date | Sun, 9 Apr 2023 23:59:35 -0700 | Subject | Re: [PATCH 4/6] seccomp: add the synchronous mode for seccomp_unotify |
| |
On Wed, Apr 5, 2023 at 8:42 PM Andy Lutomirski <luto@kernel.org> wrote: > > On Tue, Mar 7, 2023 at 11:32 PM Andrei Vagin <avagin@google.com> wrote: > > > > seccomp_unotify allows more privileged processes to do actions on behalf > > 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 to > > 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µs. With this patch, it takes about > > 3µs. > > 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 user 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 case, the user should see that both processes are running on the same cpu.
If we have one target process and one supervisor process, they synchronously 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 sleep between events), it is better to unset the flag or add more supervisor processes.
Thanks, Andrei
| |