[fuse-devel] Re: [parisc-linux] [PATCH] Fixs to work on ARM and PARIC platforms.

[Miklos Szeredi]

> > I still don't see _why_ you need all aliases flushed from
> > get_user_pages() when you are only accessing the page through a single
> > address.
> 
> Because the aliases may contain dirty cache lines.  Even if they only
> contained clean cache lines, those lines would then obscure the changed
> data is anyone accessed them.  What you're trying to do is to alter the
> user's view of a page by modifying the kernel's view of it.  This is
> what gets you into the caching problems in the first place.

Understood.

> > Think of it this way: 
> > 
> > get_user_pages(... write=0 ...) + memcpy() is equivalent to
> > copy_from_user()
> > 
> > get_user_pages(... write=1 ...) + memcpy() + flush_kernel_dcache_page()
> > is equivalent to copy_to_user()
> > 
> > copy_from_user() and copy_to_user() don't care about aliases, do they?
> 
> No, because if you look at the implementation, you'll see that
> copy_to/from_user() copy straight into the user view (i.e. via the user
> cache lines).

Yes.  But how will this ensure that the above problems (dirty/clean
cache lines in aliases) won't cause any problems?

What is the difference between

 - updating cached data through the user view

 - flushing the cache lines for the user view, then updating data
   through the kernel view and finally flushing the cache lines for
   the kernel view

I don't see in either case that the cache lines for any other aliases
are touched.  Is there still some difference in behavior?

> > So they do flush the caches _once more_ after get_user_pages() should
> > have already done so.
> 
> Well, copy_to/from_user_page() is designed to be fully cache complete,
> it certainly can't assume that someone called get_user_pages() on the
> page (like copy_to/from_user).

If you grep through the kernel tree, you'll see that
copy_to/from_user_page() are used only in access_process_vm()
(kernel/ptrace.c) and there the page _is_ obtained from
get_user_pages().

In fact this has been obscuring the bug in get_user_pages() for ptrace
users (which is probably the hottest path to it).

Miklos