[Mesa-dev] [PATCH] RFC: Workaround for pthread_setaffinity_np() seccomp filtering

[Marek Olšák]

On Thu, Feb 28, 2019 at 11:13 AM Marc-André Lureau <
marcandre.lureau at gmail.com> wrote:

> Hi Eero!
>
> (ex-colleagues, long time ago!)
>
> On Thu, Feb 28, 2019 at 1:37 PM Eero Tamminen <eero.t.tamminen at intel.com>
> wrote:
> >
> > Hi,
> >
> > On 28.2.2019 11.57, Marc-André Lureau wrote:
> > > On Thu, Feb 28, 2019 at 1:17 AM Marek Olšák <maraeo at gmail.com> wrote:
> > >> I'd rather have something more robust than an env var, like catching
> SIGSYS.
> >
> > SIGSYS is info for the invoking parent, not the (Mesa) process doing the
> > syscall.
> >
> >  From "man 2 seccomp":
> >
> > The process terminates as though killed by a SIGSYS signal.  Even if a
> > signal handler has been registered for SIGSYS,  the  handler will be
> > ignored in this case and the process always terminates.  To a parent
> > process that is waiting on this process (using waitpid(2) or similar),
> > the returned wstatus will indicate that its child was terminated as
> > though by a SIGSYS signal.
> >
> >
> > > With current qemu in most distros, it defaults to SIGSYS (we switched
> > > away from SCMP_ACT_KILL, which had other problems). With more recent
> > > qemu/libseccomp, it will default to SCMP_ACT_KILL_PROCESS. In those
> > > KILL action cases, mesa will not be able to catch the failing
> > > syscalls.
> >
> > Qemu / libvirt isn't the only thing using seccomp.
> >
> > For example Docker enables seccomp filters (along with capability
> > restrictions) for the invoked containers unless that is explicitly
> > disabled:
> >         https://docs.docker.com/engine/security/seccomp/
> >
> > What actually gets filtered, is trivially changeable on Docker command
> > line by giving a JSON file specifying the syscall filtering.
> >
> > Default policy seems to be white-listing affinity syscall:
> >
> https://github.com/moby/moby/blob/master/profiles/seccomp/default.json
> >
> >
> > Why distro versions of Qemu filter sched_setaffinity() syscall?
> >
> >
>
> (https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1815889)
>
> Daniel Berrange (berrange) wrote on 2019-02-27: #19
>
> "IMHO that mesa change is not valid. It is settings its affinity to
> run on all threads which is definitely *NOT* something we want to be
> allowed. Management applications want to control which CPUs QEMU runs
> on, and as such Mesa should honour the CPU placement that the QEMU
> process has.
>
> This is a great example of why QEMU wants to use seccomp to block
> affinity changes to prevent something silently trying to use more CPUs
> than are assigned to this QEMU."
>

Mesa uses thread affinity to optimize memory access performance on some
CPUs (see util_pin_thread_to_L3). Other places in Mesa need to restore the
original thread affinity for some child threads. Additionally, if games
limit the thread affinity, Mesa needs to restore the full thread affinity
for some of its child threads.

In essence, the thread affinity should only be considered a hint for the
kernel for optimal performance. There is no reason to kill the process if
it's disallowed. Just ignore the call or modify the thread mask to make it
legal.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190228/86382b50/attachment-0001.html>