mmap sync issue
Hugh Dickins
hughd at google.com
Sun Mar 17 22:33:25 EDT 2013
On Sat, 16 Mar 2013, Michel Lespinasse wrote:
> On Sat, Mar 16, 2013 at 4:39 PM, Will Huck <will.huckk at gmail.com> wrote:
> > On 03/15/2013 07:39 PM, Gil Weber wrote:
> >> I am experiencing an issue with my device driver. I am using mmap and
> >> ioctl to share information with my user space application.
> >> The thing is that the shared memory does not seems to be synced. Do check
> >> this, I have done a simple test:
>
> So if I got this right, the issue is that the vmalloc_area is
> virtually aliased between the kernel and the user space mapping, so
> that coherency is not guaranteed on architectures that use virtually
> aliased caches.
>
> fs/aio.c does something similar to what you want with their ring
> buffer. The kernel doesn't access the ring buffer through a vmalloc
> area like you're trying to do; instead it uses kmap_atomic() ..
> kunmap_atomic() whenever it wants to access it.
>
> I don't actually consider myself an expert in this area but I believe
> the above should solve your problem :)
I don't think so: kmap_atomic() provides a temporary kernel mapping for
a page when not all memory is direct-mapped, but it's close to a no-op
when there's no highmem. This question isn't about highmem.
I can't point to what solves the problem for the aio ringbuffer:
for all I know, that's not even used on such architectures.
The usual solution is flush_dcache_page(): see Documentation/cachetlb.txt.
Which mostly describes the common page cache case, but a driver like
yours may also need it.
Each architecture has its own implementation, and often its own way of
minimizing the overhead of flush_dcache_page(): if you're using it in
a new context, you might need to be careful about such optimizations,
and the page flags used to control them.
But better to ask on the (moderated) linux-arm-kernel list if it's not
clear to you how to use it: being a no-op on x86, those of us who know
little beyond x86 are apt to give bad advice.
Hugh
More information about the linux-arm-kernel
mailing list