[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 3089 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

            Bug ID: 109695
           Summary: qemu using spice gl and sandbox resourcecontrol=deny
                    crashes with SIGSYS on radeonsi
           Product: Mesa
           Version: 18.3
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: major
          Priority: medium
         Component: Drivers/Gallium/radeonsi
          Assignee: dri-devel@lists.freedesktop.org
          Reporter: Ahzo@tutanota.com
        QA Contact: dri-devel@lists.freedesktop.org

Since upgrading Mesa from 18.2 to 18.3, launching a QEMU virtual machine with
Spice OpenGL enabled (for virgl), causes QEMU to crash with SIGSYS inside the
radeonsi driver. The reason for this is that the QEMU sandbox option
'resourcecontrol=deny' disables the sched_setaffinity syscall called in
pthread_setaffinity_np, which is now used by the radeonsi driver.

A simple way to reproduce this problem is:
$ gdb --batch --ex run --ex bt --args qemu-system-x86_64 -spice gl=on -sandbox
on,resourcecontrol=deny
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff45aa700 (LWP 23432)]
[New Thread 0x7ffff08e5700 (LWP 23433)]
[New Thread 0x7fffe3fff700 (LWP 23434)]
[New Thread 0x7fffe37fe700 (LWP 23435)]

Thread 4 "qemu-system-x86" received signal SIGSYS, Bad system call.
[Switching to Thread 0x7fffe3fff700 (LWP 23434)]
0x00007ffff68cc9cf in __pthread_setaffinity_new (th=<optimized out>,
cpusetsize=cpusetsize@entry=128, cpuset=cpuset@entry=0x7fffe3ffe680) at
../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
34      ../sysdeps/unix/sysv/linux/pthread_setaffinity.c: No such file or
directory.
#0  0x00007ffff68cc9cf in __pthread_setaffinity_new (th=<optimized out>,
cpusetsize=cpusetsize@entry=128, cpuset=cpuset@entry=0x7fffe3ffe680) at
../sysdeps/unix/sysv/linux/pthread_setaffinity.c:34
#1  0x00007ffff12ba2b3 in util_queue_thread_func
(input=input@entry=0x55555640b1f0) at ../src/util/u_queue.c:252
#2  0x00007ffff12b9c17 in impl_thrd_routine (p=<optimized out>) at
../src/../include/c11/threads_posix.h:87
#3  0x00007ffff68c1fa3 in start_thread (arg=<optimized out>) at
pthread_create.c:486
#4  0x00007ffff67f280f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


The problematic code at src/util/u_queue.c:252 was added in the following
commit:
commit d877451b48a59ab0f9a4210fc736f51da5851c9a
Author: Marek Olšák <marek.olsak@amd.com>
Date:   Mon Oct 1 15:51:06 2018 -0400

    util/u_queue: add UTIL_QUEUE_INIT_SET_FULL_THREAD_AFFINITY

    Initial version discussed with Rob Clark under a different patch name.
    This approach leaves his driver unaffected.


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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 4596 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 253 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #1 from Marek Olšák <maraeo@gmail.com> ---
Mesa needs a way to query that it can't set thread affinity.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1104 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1163 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #2 from Ahzo@tutanota.com ---
To check for the availability of the syscall, one can try it in a child process
and see if the child is terminated by a signal, e.g. like this:

#include <stdbool.h>
#include <unistd.h>
#include <sys/resource.h>
#include <sys/syscall.h>
#include <sys/wait.h>

static bool
can_set_affinity()
{
   pid_t pid = fork();
   int status = 0;
   if (!pid) {
      /* Disable coredumps, because a SIGSYS crash is expected. */
      struct rlimit limit = { 0 };
      limit.rlim_cur = 1;
      limit.rlim_max = 1;
      setrlimit(RLIMIT_CORE, &limit);
      /* Test the syscall in the child process. */
      syscall(SYS_sched_setaffinity, 0, 0, 0);
      _exit(0);
   } else if (pid < 0) {
      return false;
   }
   if (waitpid(pid, &status, 0) < 0) {
      return false;
   }
   if (WIFSIGNALED(status)) {
      /* The child process was terminated by a signal,
       * thus the syscall cannot be used.
       */
      return false;
   }
   return true;
}

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2036 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 460 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #3 from Daniel P. Berrange <dan-freedesktop@berrange.com> ---
(In reply to Ahzo from comment #2)
> To check for the availability of the syscall, one can try it in a child
> process and see if the child is terminated by a signal, e.g. like this:

Afraid not, QEMU's seccomp filter blocks use of fork() too :-)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1402 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1308 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #4 from Daniel P. Berrange <dan-freedesktop@berrange.com> ---
(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šák <marek.olsak@amd.com>
> Date:   Mon Oct 1 15:51:06 2018 -0400
> 
>     util/u_queue: add UTIL_QUEUE_INIT_SET_FULL_THREAD_AFFINITY
>     
>     Initial version discussed with Rob Clark under a different patch name.
>     This approach leaves his driver unaffected.
> 
> 
> 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 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 ?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2344 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 760 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #5 from Alex Deucher <alexdeucher@gmail.com> ---
(In reply to Daniel P. Berrange from comment #4)
> 
> 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 ?

To improve performance on modern multi-core NUMA architectures.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1704 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 339 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #6 from Marc-Andre Lureau <marcandre.lureau@gmail.com> ---
Sent a quick RFC for an env variable workaround on the ML "[PATCH] RFC:
Workaround for pthread_setaffinity_np() seccomp filtering".

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1214 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1005 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #7 from Marek Olšák <maraeo@gmail.com> ---
(In reply to Daniel P. Berrange from comment #4)
> 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1942 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 749 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #8 from Michel Dänzer <michel@daenzer.net> ---
(In reply to Marek Olšák from comment #7)
> 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.

Mesa doesn't really need explicit thread affinity at all. All it wants is that
certain sets of threads run on the same CPU module; it doesn't care which
particular CPU module that is. What's really needed is an API to express this
affinity between threads, instead of to specific CPU cores.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1680 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 567 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

Timo Aaltonen <tjaalton@ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |109535
                 CC|                            |tjaalton@ubuntu.com


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=109535
[Bug 109535] [Tracker] Mesa 19.0 release tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1773 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 1070 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #9 from Ahzo@tutanota.com ---
(In reply to Daniel P. Berrange from comment #3)
> (In reply to Ahzo from comment #2)
> > To check for the availability of the syscall, one can try it in a child
> > process and see if the child is terminated by a signal, e.g. like this:
> 
> Afraid not, QEMU's seccomp filter blocks use of fork() too :-)

Maybe it should, at least when using the spawn=deny option, but currently it
doesn't. That option only blocks the fork, vfork and execve syscalls, but
glibc's fork() function uses the clone syscall, and thus continues to work.
However, that behavior might be different when using other C library
implementations, so it wouldn't be correct to rely on this.
One could use clone() instead of fork(), but future versions of qemu might
block the clone syscall, as well.

Unfortunately, I'm not aware of a proper solution for this bug short of adding
a new API to the kernel.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2028 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 307 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #10 from Dylan Baker <baker.dylan.c@gmail.com> ---
We're getting down to just a few bugs blocking 19.0, so I'm pinging those bugs
to see what the progress is?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1164 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 872 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

Dylan Baker <baker.dylan.c@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|109535                      |

--- Comment #11 from Dylan Baker <baker.dylan.c@gmail.com> ---
I'm removing this from the 19.0 blocking tracker. Generally we don't add bugs
to block a release if they were present in the previous release, additionally
there doesn't seem to be any consensus on a solution, at this moment. If there
is a fix implemented I'd be happy to pull that into a later 19.0 release.


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=109535
[Bug 109535] [Tracker] Mesa 19.0 release tracker
-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2652 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 718 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

--- Comment #12 from Marek Olšák <maraeo@gmail.com> ---
(In reply to Michel Dänzer from comment #8)
> Mesa doesn't really need explicit thread affinity at all. All it wants is
> that certain sets of threads run on the same CPU module; it doesn't care
> which particular CPU module that is. What's really needed is an API to
> express this affinity between threads, instead of to specific CPU cores.

I think the thread affinity API is a correct way to optimize for CPU cache
topologies. pthread is a basic user API. Security policies shouldn't disallow
pthread functions.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 1650 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109695] qemu using spice gl and sandbox resourcecontrol=deny crashes with SIGSYS on radeonsi

[bugzilla-daemon]

[-- Attachment #1.1: Type: text/plain, Size: 631 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=109695

Ahzo@tutanota.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |NOTOURBUG

--- Comment #13 from Ahzo@tutanota.com ---
This problem was solved by qemu [1], so this mesa bug can be closed.

[1]
https://git.qemu.org/git/qemu.git/?a=commitdiff;h=9a1565a03b79d80b236bc7cc2dbce52a2ef3a1b8

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2306 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel