Re: [PATCH v2] drm: enable render-nodes by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 20, 2014 at 10:44:10AM -0400, Ilia Mirkin wrote:
> On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse <j.glisse@xxxxxxxxx> wrote:
> > On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote:
> >> On 03/20/2014 10:43 AM, David Herrmann wrote:
> >> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
> >> > <thellstrom@xxxxxxxxxx> wrote:
> >> > Given that the legacy node is always around and _always_ has these
> >> > races, why should we prevent render-nodes from appearing just because
> >> > the _driver_ is racy? I mean, there is no gain in that.. if it opens a
> >> > new race, as you assumed, then yes, we should avoid it. But at least
> >> > for all drivers supporting render-nodes so far, they either are
> >> > entirely safe or the just described races exist on both nodes.
> >>
> >> My suggestion is actually not to prevent render nodes from appearing,
> >> but rather that we should restrict them to drivers with command stream
> >> verification and / or per process virtual memory, and I also think we
> >> should plug the above races on legacy nodes. That way legacy nodes would
> >> use the old "master owns it all" model, while render nodes could allow
> >> multiple users at the same time.
> >
> > FYI both radeon and nouveau (last time i check) can not be abuse to access
> > random VRAM or buffer bind by another process (except if the buffer is share
> > of course).
> 
> I'm not aware of any restrictions in nouveau that would prevent you
> from accessing any vram... there are a number of copy engines
> accessible that would allow you to copy one region to another, and I'm
> not aware of code to validate pushbuf contents (it would have to parse
> the pushbuf and know which methods store source/destination
> addresses). You could probably get creative and use that to overwrite
> the MMU tables, to then gain the ability to read/write any part of
> system memory... but perhaps the engines won't allow you to do that,
> not sure. (Or perhaps the PDE isn't mapped into VRAM. Again, not
> sure.)
> 
>   -ilia

Well i obviously have not look at that in long time, but if the nouveau
API can be abuse than i consider this a broken by design. I know command
checking is painfull and CPU intensive but we have done it in radeon for
a reason.

Cheers,
Jérôme
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel





[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux