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 AM, Ilia Mirkin <imirkin@xxxxxxxxxxxx> 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.)

Please ignore this totally wrong comment. While there is indeed no
pushbuf validation, every process (well, every open() of the drm node)
gets its own virtual memory space for all GPU's with MMU's (nv50+).

  -ilia
_______________________________________________
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