On Mon, Apr 13, 2015 at 11:52:19AM -0400, Serguei Sagalovitch wrote: > > Given that the userspace wait fence ioctl has not way to know which > > command buffer it is really waiting after then kernel has no knowledge > > if this user fence will signal at all. > > We could pass BO handle as parameter in the "fence ioctl" to rely on it so > kernel will know which BO it is waiting. Christian code already do that, but this is not enough to know which cs kernel is waiting for. See my other emails with Christian. > > > > So a malicious user space (we always have to assume this thing exist) > > could create a big VRAM BO and effectively pin it in VRAM leading to a GPU > > DOS (denial of service). > > This problem always exists. Malicious user space could allocate big BO and > then submit shader running in loop which read/write from this BO. It could > also spawn processes which will do the same thing. IMHO the only way to > improve situation is to have GPU Scheduler to allow "unloading" such > application. > Yes but the GPU lockup watchdog would kick in (thinking it is a GPU lockup) and reset the GPU which is harsh but that is what we have now (well i think the compute guys messed with that so it might no longer be the case). So it is just about avoiding giving userspace more means to mess with thing. Cheers, Jérôme _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
