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

[Inki Dae]

2013/9/29 Inki Dae <inki.dae at samsung.com>

>
>
> 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.
>

Sorry, there was a wrong comment. it's not all ARM SoC have no iommu.
Exynos also has the iommu, and maybe recently most SoCs.


>
> 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/1547d8e0/attachment.html>