Messages in this thread | ![/](/images/icornerl.gif) | | Date | Fri, 22 Aug 2003 12:19:55 -0700 | From | "David S. Miller" <> | Subject | Re: [parisc-linux] Re: Problems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc) |
| |
On 22 Aug 2003 13:56:06 -0500 James Bottomley <James.Bottomley@SteelEye.com> wrote:
> On Fri, 2003-08-22 at 13:31, David S. Miller wrote: > > On Fri, 22 Aug 2003 19:34:41 +0100 (BST) > > Hugh Dickins <hugh@veritas.com> wrote: > > > > > And to me. If VM_SHARED is set, then __vma_link_file puts the vma on > > > on i_mmap_shared. If VM_SHARED is not set, it puts the vma on i_mmap. > > > flush_dcache_page treats i_mmap_shared and i_mmap lists equally. > > > > But file system page cache writes only call flush_dache_page() > > if the page has a non-empty i_mmap_shared list. > > Hmm, but if it does that then the glibc bug test should show up on sparc > because the i_mmap_shared list is empty if we only do MAP_SHARED of read > only files.
Sparc64's alias'able caches are 1) write-through and 2) quite small.
I think I begin to see the issue clearly now.
But you cannot do the VM_SHARED change without an audit first. Lots of code thinks that VM_SHARED means someone maybe wrote to the page through a mmap(). For example look at how filemap sync interprets this flag bit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |