<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi" href="https://bugs.freedesktop.org/show_bug.cgi?id=109695#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi" href="https://bugs.freedesktop.org/show_bug.cgi?id=109695">bug 109695</a> from <a class="email" href="mailto:maraeo@gmail.com" title="Marek Olšák <maraeo@gmail.com>"> Marek Olšák</a> <pre>(In reply to Daniel P. Berrange from <a href="show_bug.cgi?id=109695#c4">comment #4</a>) > I'm curious what motivated this change to start with ? Even if QEMU was not > enforcing seccomp filters, I think I'd consider it a bug for mesa to be > setting its process affinity in this way. The mgmt application or sysadmin > has decided that the process must have a certain affinity, based on how > it/they want the host CPUs utilized. Why is mesa wanting to override this > administrative policy decision to restrict CPU usage ? The correct solution is to fix pthread_setaffinity such that it returns an error code instead of crashing. An even better solution would be to have a virtual thread affinity that only the application can see and change, which should be silently masked by administrative policies not visible to the application.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>