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

[Mathias Fröhlich]

On Friday, 1 March 2019 12:15:08 CET Eero Tamminen wrote:
> Hi,
> 
> On 1.3.2019 11.12, Michel Dänzer wrote:
> > On 2019-02-28 8:41 p.m., Marek Olšák wrote:
> >>> On Thu, Feb 28, 2019 at 1:37 PM Eero Tamminen <eero.t.tamminen at intel.com>
> >>>> 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.
> > 
> > The last part sounds like Mesa clearly overstepping its authority.
> > 
> > 
> >> 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.
> > 
> > The fundamental issue here is that Mesa is using the thread affinity API
> > for something else than it's intended for. If there was an API for what
> > Mesa wants (encouraging certain sets of threads to run on topologically
> > close cores), there should be no need to block that.
> 
> Why such process needs to be killed instead the request being masked 
> suitably, is there some program that breaks subtly if affinity request 
> is masked (and that being worse than the program being killed)?

But that is still a situation that could be nicely handled with a
EPERM error return. Way better than just kill a process.
That 'badly affected' program still can call abort then.
But nicely working programs don't get just killed then!!

best

Mathias

> 
> 
> 	- eero
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev