[parisc-linux] Re: [fuse-devel] Example filesystem fail to init on parisc

[Hugh Dickins]

On Sun, 19 Mar 2006, James Bottomley wrote:
> On Sun, 2006-03-19 at 15:38 +0000, Hugh Dickins wrote:
> > Certainly, that is part of what copy_to_user and get_user_pages(,,,,1,,,)
> > (and ordinary userspace writing) guarantee.  So if there's some new route
> > by which userspace pages may be modified on behalf of the user, never mind
> > the architecture-specific cache coherency issues, COWs must be broken to
> > preserve the semantics of fork.
> 
> Yes, that's where I think the problem lies.  For an anonymous unshared
> page, the user view of the cache may still be dirty.  get_user_pages()
> only seems to use flush_dcache_page() to restore coherency, which won't
> work on anon pages.  Thus, get_user_pages() for an anon page is
> returning a page to the kernel that still has an incoherent user cache,
> which is what causes the issues in the copytest module.
> 
> > drivers/scsi/sg.c looks like it makes all the necessary calls to
> > __copy_to_user or get_user_pages... but it's not hard to fool me.
> 
> Yes ... and the copytest module has an almost exact duplicate of that
> code ... it's the actual get_user_pages() where I think we have
> coherency issues ... I've verified that it is returning an incoherent
> page if the underlying user page is PAGE_MAPPING_ANON.

It sounds like an issue you need to raise on linux-arch?  I've no idea
whether it's the parisc implementation of flush_dcache_page which is
at fault (skipping anonymous pages), or that get_user_pages ought to
be calling something stronger (something new?).  Remember, I'm one of
those x86 people with only a nursery-school grasp of coherency issues.

I do see that when flush_dcache_page was added into get_user_pages in
2.5.46, the parisc flush_dcache_page looked to be doing something else,
something which would have caught the anonymous pages.  And I just
looked up the ChangeLog-2.5.46 entry, below: akpm and davem CC'ed.

<akpm at digeo.com>
  [PATCH] flush_dcache_page in get_user_pages()
  
  Davem said:
  
  "Ho hum, it is tricky :-)))
  
   At bio_map_user() you need to see the user's most recent write to the
   page if you are going "user --> device".  So if "user --> device"
   bio_map_user() must flush_dcache_page().
  
   I find the write_to_vm condition confusion which is probably why I am
   sitting here spelling this out :-)
  
   At bio_unmap_user(), if we are going "device --> user" you have to
   flush_dcache_page().  And actually, this flush could just as
   legitimately occur at bio_map_user() time.
  
   Therefore, the easiest thing to do is always flush_dcache_page() at
   bio_map_user().
  
   All the other cases are going to be like this, so we might as well
   cut to the chase and flush_dcache_page() for all the pages inside of
   get_user_pages()."