Re: Properly implement flush_dcache_page in 2.4? (Or is it

[Hugh Dickins]

On Sat, 31 May 2003, Russell King wrote:
> On Sat, May 31, 2003 at 08:24:00AM +0100, Hugh Dickins wrote:
> > On Sat, 31 May 2003, Russell King wrote:
> > > 
> > > I don't see a reason to worry about privately mapped pages on the i_mmap
> > > list since they are private, and therefore shouldn't be updated with
> > > modifications to other mappings, which I'd have thought would include
> > > writes to the file (although I'm not so sure atm.)
> > 
> > Be not so sure.  vmas on the private i_mmap list can still contain
> > shared pages, which should see writes to the file; but of course their
> > already-COWed private pages won't see subsequent writes to the file.
> 
> Hmm, looking at the posix spec (do we follow POSIX for mmap?) the
> behaviour of MAP_PRIVATE mappings when the underlying file is modified
> is unspecified.
> 
> I guess missing the cache handling for such mappings fits the POSIX
> spec, and is equally as yucky as the current behaviour on CPUs which
> don't require these flushes.
> 
> (unless someone tells me that POSIX is on drugs, I'm not going to be
> that bothered about the MAP_PRIVATE case.)

I was about to concede to you: just because the pages are shared doesn't
mean that _you_ have to be overanxious about immediately forcing changes
to be visible to userspace (though it would be unfriendly if updates were
to appear at lesser granularity than PAGE_SIZE: I've no idea whether
that's a possibility), the "unspecified" would allow that much - but
wouldn't allow you to show portions of entirely other files!

But I've just remembered the peculiar VM_SHARED handling in mm/mmap.c:
open a file O_RDONLY, mmap it PROT_READ MAP_SHARED, and the vma will be
put on the i_mmap list, not on the i_mmap_shared list.  So the i_mmap
list can actually contain shared mappings, not just private mappings.
Poor naming certainly: the i_mmap_shared list is for mappings though
which the object might be modified.

Hugh