[PATCH 0/2 v4] drm/exynos: added userptr feature

[Inki Dae]

ccing linux-mm

> -----Original Message-----
> From: Inki Dae [mailto:inki.dae at samsung.com]
> Sent: Monday, May 14, 2012 3:18 PM
> To: airlied at linux.ie; dri-devel at lists.freedesktop.org
> Cc: j.glisse at gmail.com; minchan at kernel.org; kosaki.motohiro at gmail.com;
> kyungmin.park at samsung.com; sw0312.kim at samsung.com;
jy0922.shim at samsung.com;
> Inki Dae
> Subject: [PATCH 0/2 v4] drm/exynos: added userptr feature
> 
> this feature could be used to 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.
> 
> Changelog v4:
> we have discussed some issues to userptr feature with drm and mm guys and
> below are the issues.
> 
> The migration issue.
> - Pages reserved by CMA for some device using DMA could be used by
> kernel and if the device driver wants to use those pages
> while being used by kernel then the pages are copied into
> other ones allocated to migrate them and then finally,
> the device driver can use the pages for itself.
> Thus, migrated, the pages being accessed by DMA could be changed
> to other so this situation may incur that DMA accesses any pages
> it doesn't want.
> 
> The COW issue.
> - while DMA of a device is using the pages to VMAs, if current
> process was forked then the pages being accessed by the DMA
> would be copied into child's pages.(Copy On Write) so
> these pages may not have coherrency with parent's ones if
> child process wrote something on those pages so we need to
> flag VM_DONTCOPY to prevent pages from being COWed.
> 
> But the use of get_user_pages is safe from such magration issue
> because all the pages from get_user_pages CAN NOT BE not only
> migrated but also swapped out. this true has been confirmed
> by mm guys, Minchan Kim and KOSAKI Motohiro.
> However below issue could be incurred.
> 
> The deterioration issue of system performance by malicious process.
> - any malicious process can request all the pages of entire system memory
> through this userptr ioctl and as the result, all other processes would be
> blocked and this would incur the deterioration of system performance
> because the pages couldn't be swapped out.
> 
> So we limit user-desired userptr size to pre-defined and this ioctl
> command
> CAN BE accessed by only root user.
> 
> Changelog v3:
> Mitigated the issues pointed out by Dave and Jerome.
> 
> for this, added some codes to guarantee the pages to user space not
> to be swapped out, the VMAs within the user space would be locked and
> then unlocked when the pages are released.
> 
> but this lock might result in significant degradation of system
> performance
> because the pages couldn't be swapped out so added one more featrue
> that we can limit user-desired userptr size to pre-defined value using
> userptr limit ioctl that can be accessed by only root user.
> 
> Changelog v2:
> the memory regino mmaped with VM_PFNMAP type is physically continuous and
> start address of the memory region should be set into buf->dma_addr but
> previous patch had a problem that end address is set into buf->dma_addr
> so v2 fixes that problem.
> 
> Inki Dae (2):
>   drm/exynos: added userptr limit ioctl.
>   drm/exynos: added userptr feature.
> 
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |    8 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h |    6 +
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |  413
> +++++++++++++++++++++++++++++++
>  drivers/gpu/drm/exynos/exynos_drm_gem.h |   20 ++-
>  include/drm/exynos_drm.h                |   43 +++-
>  5 files changed, 487 insertions(+), 3 deletions(-)
> 
> --
> 1.7.4.1