On Sat, Dec 30, 2006 at 10:26:20AM -0800, Linus Torvalds wrote:
>
>
> On Sat, 30 Dec 2006, Russell King wrote:
> >
> > And here's the flush_anon_page() part.
> >
> > Add flush_anon_page() for ARM, to avoid data corruption issues when using
> > fuse or other subsystems using get_user_pages().
>
> Btw, since this doesn't actually change any code for anybody but ARM, just
> adds a parameter that is obviously unused by everybody else, and if it
> actually fixes a real bug for ARM, I'll obviously happily take it even
> before 2.6.20. So go ahead put it in your ARM tree, and we'll get some
> testing through that. And just ask me to pull at some point.
>
> I wonder why nobody else seems to have a "flush_anon_page()"? This would
> seem to be a potential issue for architectures like sparc too.. Although
> maybe sparc can do a flush by physical index with "flush_dcache_page()".
Well...
iirc, flush_anon_page() was introduced to fix non-working fuse on parisc,
which occurs because fuse wants to use get_user_pages() to read data from
the current processes memory space.
get_user_pages() contains a call to flush_dcache_page(), whose behaviour
is defined for shared mappings. Anonymous pages are unspecified. It
appears that flush_anon_page() was introduced to correct this oversight.
Looking at some of the other users of get_user_pages() which want to
access the current processes memory space, one finds the following:
some use flush_cache_page():
- binfmt_elf coredump
- ptrace (in arch code)
others don't:
- aio
- bio
- block (block_dev::blk_get_page seems to be for direct-io, there's problems
reported with this on ARM)
- direct-io
- fuse
- vmsplice
So, anything except coredumps and ptrace are currently unsafe on ARM
without something being added to get_user_pages() to ensure coherency
of anonymous pages.
Given that we have reported corruption with direct-io, and debian bug
#402876 for nonworking fuse, it seems the correct thing to do is to
implement this function.
--
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
- Prev by Date:
Re: replace "memset(...,0,PAGE_SIZE)" calls with "clear_page()"?
- Next by Date:
Re: replace "memset(...,0,PAGE_SIZE)" calls with "clear_page()"?
- Previous by thread:
Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
- Next by thread:
Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again
- Index(es):
[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]