Hi,
On 12.3.2019 10.59, Marc-André Lureau wrote:
On Fri, Mar 1, 2019 at 12:13 PM Mathias Fröhlich
<mathias.froehl...@gmx.net> wrote:
On Friday, 1 March 2019 12:15:08 CET Eero Tamminen wrote:
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.tammi...@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!!
Returning an error seems less secure that prohibiting it completely.
And it may lead to subtle bugs in rarely tested code paths.
It's legitimate that QEMU and management layers want to prevent
arbitrary code from changing resource allocation etc.
They can do that by no-oping the system call, or masking the parts they
don't want to be modified. As that affects only (potentially)
performance, not functionality, it seems to me better than outright
killing a process.
(As with killing, there should probably be some way to log things that
were ignored/masked.)
There are no easy way I can think of for mesa (and other libraries) to
probe the seccomp filters and associated action.
So we need a way to tell mesa not to call setaffinity() (and other
syscalls). MESA_NO_THREAD_AFFINITY or MESA_NO_SYSCALLS=setaffinity,...
seem like a relatively easy way to go.
- Eero
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
