Re: [RFC] drm/radeon: userfence IOCTL

[Jerome Glisse <j.glisse@gmail.com>]

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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel