RE: [PATCH v2 3/4] drm/exynos: added userptr feature.

[Inki Dae <inki.dae@samsung.com>]

Hi Jerome,

> -----Original Message-----
> From: Jerome Glisse [mailto:j.glisse@gmail.com]
> Sent: Tuesday, May 08, 2012 3:18 AM
> To: Dave Airlie
> Cc: daeinki@gmail.com; Inki Dae; kyungmin.park@samsung.com;
> sw0312.kim@samsung.com; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH v2 3/4] drm/exynos: added userptr feature.
> 
> On Sat, May 5, 2012 at 6:22 AM, Dave Airlie <airlied@gmail.com> wrote:
> > On Sat, May 5, 2012 at 11:19 AM,  <daeinki@gmail.com> wrote:
> >> Hi Dave,
> >>
> >> 2012. 4. 25. 오후 7:15 Dave Airlie <airlied@gmail.com> 작성:
> >>
> >>> On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae <inki.dae@samsung.com>
wrote:
> >>>> this feature could be used to use memory region allocated by malloc()
> in user
> >>>> mode and mmaped memory region allocated by other memory allocators.
> userptr
> >>>> interface can identify memory type through vm_flags value and would
> get
> >>>> pages or page frame numbers to user space appropriately.
> >>>
> >>> Is there anything to stop the unpriviledged userspace driver locking
> >>> all the RAM in the machine inside userptr?
> >>>
> >>
> >> you mean that there is something that it can stop user space driver
> locking some memory region  of RAM? and if any user space driver locked
> some region then anyone on user space can't access the region? could you
> please tell me about your concerns in more detail so that we can solve the
> issue? I guess you mean that any user level driver such as specific EGL
> library can allocate some memory region and also lock the region so that
> other user space applications can't access the region until rendering is
> completed by hw accelerator such as 2d/3d core or opposite case.
> >>
> >> actually, this feature has already been used by v4l2 so I didn't try to
> consider we could face with any problem with this and I've got a feeling
> maybe there is something I missed so I'd be happy for you or anyone give
> me any advices.
> >
> > Well v4l get to make their own bad design decisions.
> >
> > The problem is if an unprivledged users accessing the drm can lock all
> > the pages it allocates into memory, by passing them to the kernel as
> > userptrs., thus bypassing the swap and blocking all other users on the
> > system.
> >
> > Dave.
> 
> Beside that you are not locking the vma and afaik this means that the
> page backing the vma might change, yes you will still own the page you
> get but userspace might be reading/writing to different pages. The vma

Yes, right. the vma should be locked because the pages backing the vma
might be changed after swap-in. thank you for your pointing.


> would need to be locked but than the userspace might unlock it in your
> back and you start right from the begining.
> 

I'm not sure I understood your comments but my understanding is you mean
that there is some interface that it can unlock(using some interface of drm
side or implementing it?) the vma so we can resolve the issue Dave pointed
out?

Thanks,
Inki Dae

> Cheers,
> Jerome

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel