On Wed, Mar 13, 2019 at 02:29:28PM +0100, Marc-André Lureau wrote: > Hi > > On Wed, Mar 13, 2019 at 8:53 AM Mathias Fröhlich > <mathias.froehl...@gmx.net> wrote: > > > > Marek, Marc-Andre, > > > > On Wednesday, 13 March 2019 00:03:26 CET Marek Olšák wrote: > > > The env var workaround is fine. > > > > > > Thread affinity is used for cache topology related optimizations. I think > > > it's a mistake to treat it only as a resource allocation tool. > > > > For a shorter term solution to the problem. > > One Idea that comes into my mind: > > > > Can we check the currently set thread affinity mask if it still contains the > > cpu we are aiming for and narrow the mask down to our cpu if we can do > > that by narrowing. If we would need to assign our thread to a cpu that > > we are not bound anymore just do nothing. > > > > getaffinity() is also blocked by current qemu policy.
I think we could consider that a bug. Blocking this syscall while still allowing read of /proc/self/status achieves little from a security pov as the affinity is still visible. It is just protecting against a bug in the impl of getaffinity in the kernel which is unlikely to be worth caring about & a bug in /proc impl is probably more likely! Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev