[RFC] deadlock in "drm/exynos: fix wrong pointer access at vm close"

Inki Dae inki.dae at samsung.com
Sat Sep 28 10:47:20 PDT 2013


2013/9/26 Al Viro <viro at zeniv.linux.org.uk>

> On Wed, Sep 25, 2013 at 01:34:30PM +0900, Inki Dae wrote:
>
> > It seems that we can use a new anon file instead of using drm file to
> > resolve the issue.
>
> Could you describe what are you trying to achieve with that ioctl() and
> what semantics do you want from normal mmap()?
>

Ok, The reason that we are using ioctl mmap is that I thought it doesn't
need demand paging mechanism for drm driver for ARM SoCs: they have no
iommu so need physically continuous memory for DMA.

And another reason is that dumb* interface - it seems that you say this
interface is a normal mmap but this is a fake mmap - has more steps against
ioctl mmap. So to map some user space with physical pages, first,
application should request a gem allocation, and then request a hash key of
the allcated gem, and then fake mmap. This fake mmap system call doesn't
map a given user space with the physical pages. And then the user space
will be mapped with the physical pages by page fault handler when cpu tries
to access the user space. On the other hand, the ioctl mmap call will
map the user space with physical pages, and I thought this way would have
better performance than normal mmap at least in case of ARM based SoC.

And last, the reason I had implemented the normal mmap is that dumb*
interfaces are required as default. i.e. modetest app of libdrm uses only
dumb interfaces for buffer management.

Anyway,we have faced with some issues by using ioctl mmap and normal mmap
together, and these issues should be fixed.


Thanks,
Inki Dae


> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130929/af27294c/attachment.html>


More information about the dri-devel mailing list