Hi, Just catching up on this thread now. My main question is where is issue occurring? Is it some sort of CI system or something along those lines? We don't really consider SWR in an emulated environment to be an intended use case. Generally it is used as the rendering backend for data visualization, which is typically running on the host OS.
-Alok > -----Original Message----- > From: mesa-dev [mailto:mesa-dev-boun...@lists.freedesktop.org] On > Behalf Of Marc-André Lureau > Sent: Thursday, February 28, 2019 10:14 AM > To: Tamminen, Eero T <eero.t.tammi...@intel.com> > Cc: ML mesa-dev <mesa-dev@lists.freedesktop.org> > Subject: Re: [Mesa-dev] [PATCH] RFC: Workaround for > pthread_setaffinity_np() seccomp filtering > > Hi Eero! > > (ex-colleagues, long time ago!) > > On Thu, Feb 28, 2019 at 1:37 PM Eero Tamminen > <eero.t.tammi...@intel.com> wrote: > > > > Hi, > > > > On 28.2.2019 11.57, Marc-André Lureau wrote: > > > On Thu, Feb 28, 2019 at 1:17 AM Marek Olšák <mar...@gmail.com> > wrote: > > >> I'd rather have something more robust than an env var, like catching > SIGSYS. > > > > SIGSYS is info for the invoking parent, not the (Mesa) process doing > > the syscall. > > > > From "man 2 seccomp": > > > > The process terminates as though killed by a SIGSYS signal. Even if a > > signal handler has been registered for SIGSYS, the handler will be > > ignored in this case and the process always terminates. To a parent > > process that is waiting on this process (using waitpid(2) or similar), > > the returned wstatus will indicate that its child was terminated as > > though by a SIGSYS signal. > > > > > > > With current qemu in most distros, it defaults to SIGSYS (we > > > switched away from SCMP_ACT_KILL, which had other problems). With > > > more recent qemu/libseccomp, it will default to > > > SCMP_ACT_KILL_PROCESS. In those KILL action cases, mesa will not be > > > able to catch the failing syscalls. > > > > Qemu / libvirt isn't the only thing using seccomp. > > > > For example Docker enables seccomp filters (along with capability > > restrictions) for the invoked containers unless that is explicitly > > disabled: > > https://docs.docker.com/engine/security/seccomp/ > > > > What actually gets filtered, is trivially changeable on Docker command > > line by giving a JSON file specifying the syscall filtering. > > > > Default policy seems to be white-listing affinity syscall: > > > > > https://github.com/moby/moby/blob/master/profiles/seccomp/default.jso > n > > > > > > 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." > > > > -- > Marc-André Lureau > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
