ccing linux-mm > -----Original Message----- > From: Inki Dae [mailto:inki....@samsung.com] > Sent: Monday, May 14, 2012 3:18 PM > To: airl...@linux.ie; dri-devel@lists.freedesktop.org > Cc: j.gli...@gmail.com; minc...@kernel.org; kosaki.motoh...@gmail.com; > kyungmin.p...@samsung.com; sw0312....@samsung.com; jy0922.s...@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
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
