On Thu, Dec 21, 2006 at 07:30:11PM +0100, Miklos Szeredi wrote:
> > > > > Yes, note the flush_dcache_page() call in fuse_copy_finish(). That
> > > > > could be replaced by the flush_kernel_dcache_page() (added by James
> > > > > Bottomley together with flush_anon_page()) when all relevant
> > > > > architectures have defined it.
> > > >
> > > > I should say that flush_anon_page() in its current form is going to be
> > > > problematic for ARM. It is passed:
> > > >
> > > > 1. the struct page
> > > > 2. the virtual address in process memory for the page
> > > >
> > > > It is not passed the mm or vma. This means that we have no idea whether
> > > > the virtual address is in the currently mapped VM space or not. The
> > > > common use of get_area_pages() is to get pages from other address
> > > > spaces.
> > >
> > > I'm not sure I understand. flush_anon_page() needs only to flush the
> > > mapping for the given virtual address, no?
> >
> > Yes, but that virtual /user/ address is meaningless without knowing
> > which process address space it belongs to.
> >
> > > It's always mapped at that address (since it was just accessed through
> > > that).
> >
> > No. Consider ptrace() (invoked by gdb) reading data from another
> > processes address space to obtain structure data or instructions.
> >
> > > Any other mappings
> > > of the anonymous page are irrelevant, they don't need to be flushed.
> >
> > Again, incorrect. Consider if the page you're accessing is a file-
> > backed page, and is mapped into a process using a shared mapping.
> > Because you've written to the file, those shared mappings need to see
> > that write, and the interface for achieving that is flush_dcache_page().
> > If not, data loss can occur.
>
> Yes, for file backed pages. But flush_anon_page() only needs to deal
> with anonymous (not file backed) pages.
Ignore my final paragraph, it was clearly wrong; I was thinking about
the flush after you've written to the page.
However, I continue to assert that I require the VMA to implement
flush_anon_page() since a userspace address without knowing which
userspace it corresponds with is utterly useless for cache maintainence
purposes.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
- Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
- Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
- Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
- Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
- Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]