From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi Date: Wed, 27 Feb 2019 14:45:24 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1663568748==" Return-path: Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id CB8A76E0E4 for ; Wed, 27 Feb 2019 14:45:23 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1663568748== Content-Type: multipart/alternative; boundary="15512787231.FEDbA0.2829" Content-Transfer-Encoding: 7bit --15512787231.FEDbA0.2829 Date: Wed, 27 Feb 2019 14:45:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated https://bugs.freedesktop.org/show_bug.cgi?id=3D109695 --- Comment #4 from Daniel P. Berrange --- (In reply to Ahzo from comment #0) > The problematic code at src/util/u_queue.c:252 was added in the following > commit: > commit d877451b48a59ab0f9a4210fc736f51da5851c9a > Author: Marek Ol=C5=A1=C3=A1k > Date: Mon Oct 1 15:51:06 2018 -0400 >=20 > util/u_queue: add UTIL_QUEUE_INIT_SET_FULL_THREAD_AFFINITY >=20=20=20=20=20 > Initial version discussed with Rob Clark under a different patch name. > This approach leaves his driver unaffected. >=20 >=20 > Since setting the thread affinity seems non-essential here, the failing > syscall should be handled gracefully, for example by setting a signal > handler to ignore the SIGSYS signal. 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 set= ting its process affinity in this way. The mgmt application or sysadmin has dec= ided 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 pol= icy decision to restrict CPU usage ? --=20 You are receiving this mail because: You are the assignee for the bug.= --15512787231.FEDbA0.2829 Date: Wed, 27 Feb 2019 14:45:23 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated

Commen= t # 4 on bug 10969= 5 from Daniel P. Berrange<= /a> 
(In reply to Ahzo from comment #0)
> The problematic code at src/util/u_queue.c:252 w=
as added in the following
> commit:
> commit d877451b48a59ab0f9a4210fc736f51da5851c9a
> Author: Marek Ol=C5=A1=C3=A1k <marek.olsak@amd.com>
> Date:   Mon Oct 1 15:51:06 2018 -0400
>=20
>     util/u_queue: add UTIL_QUEUE_INIT_SET_FULL_THREAD_AFFINITY
>=20=20=20=20=20
>     Initial version discussed with Rob Clark under a different patch n=
ame.
>     This approach leaves his driver unaffected.
>=20
>=20
> Since setting the thread affinity seems non-essential here, the failing
> syscall should be handled gracefully, for example by setting a signal
> handler to ignore the SIGSYS signal.

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 set=
ting
its process affinity in this way.  The mgmt application or sysadmin has dec=
ided
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 pol=
icy
decision to restrict CPU usage ?

You are receiving this mail because:
  • You are the assignee for the bug.
= --15512787231.FEDbA0.2829-- --===============1663568748== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============1663568748==--