[PATCH v2 3/4] drm/exynos: added userptr feature.
inki.dae at samsung.com
Mon May 7 23:48:52 PDT 2012
> -----Original Message-----
> From: Dave Airlie [mailto:airlied at gmail.com]
> Sent: Saturday, May 05, 2012 7:23 PM
> To: daeinki at gmail.com
> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org
> Subject: Re: [PATCH v2 3/4] drm/exynos: added userptr feature.
> On Sat, May 5, 2012 at 11:19 AM, <daeinki at gmail.com> wrote:
> > Hi Dave,
> > 2012. 4. 25. 오후 7:15 Dave Airlie <airlied at gmail.com> 작성:
> >> On Tue, Apr 24, 2012 at 6:17 AM, Inki Dae <inki.dae at 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.
> >>> interface can identify memory type through vm_flags value and would
> >>> 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
Thank you for your advices and comments and I will look over this feature
We should use this feature for our linux-based platform because the backend
of evas(used by elementary) or pixman(used by Cario) needs this feature to
use hardware accelerator only using user address so I will re-post it again
after resolving this issue if possible.
More information about the dri-devel