Question about ION carveout heap support partial cache flush

[Russell King - ARM Linux]

On Mon, Aug 27, 2012 at 09:43:10PM +0800, Haojian Zhuang wrote:
> On Mon, Aug 27, 2012 at 4:29 PM, Russell King - ARM Linux
> <linux at arm.linux.org.uk> wrote:
> > On Mon, Aug 27, 2012 at 04:23:31PM +0800, zhangfei gao wrote:
> >> On Mon, Aug 27, 2012 at 1:46 PM, Haojian Zhuang
> >> <haojian.zhuang at gmail.com> wrote:
> >> > Let me summerize it. First, user space address is mapped. Then,
> >> > flushing user space
> >> > address is triggered. It's a workaround of fixing non-existed virtual
> >> > address without fixing
> >> > vmap() or any other solution. It's just a quick fix.
> >> >
> >> > Zhangfei,
> >> > I doubt that the issue may be caused by missing memory barrier.
> >> > Flushing is using
> >> > coprocessor instructions. It's a little different.
> >>
> >> Is there any limitation that dmac_map_area & dmac_flush_range
> >> supporting addr mapped from user space?
> >
> > They DEFINITELY DO NOT SUPPORT FLUSHING USER SPACE.
> 
> I agree that those API are defined to support kernel space address only.
> But the implementation is only flushing address by assembly code.

No.  Have you looked at what the dma_map_page() and scatterlist stuff
does?  It all wants to deal with a 'struct page'.  Have you looked at
how L2 caches are handled?  That wants to be able to use virt_to_phys
and similar to convert addresses, which only work on the linear mapped
region.

Have you thought about what happens when the user's page gets unmapped
or swapped out (or even just aged) ?  I don't think you've given any of
this any consideration what so ever.

There's more here than just "oh we can just pass random address X into
this function and hope that nothing goes wrong."  It's really not that
simple.