Re: [PATCH 4/6] seccomp: add the synchronous mode for seccomp_unotify

[Andy Lutomirski]

On Sun, Apr 9, 2023, at 11:59 PM, Andrei Vagin wrote:
> On Wed, Apr 5, 2023 at 8:42 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote:
>>
>> On Tue, Mar 7, 2023 at 11:32 PM Andrei Vagin <avagin@xxxxxxxxxx> 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.

So I think you're saying it has no semantic effect.  It's a performance thing.

>
> 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.

ISTM the kernel ought to be able to handle this much more automatically.  The scheduler knows whether the target is running and how busy it has been.

I'm not sure what the right heuristic is in the kernel, but I'm also not convinced that user code has any particular insight here.