lkml.org 
[lkml]   [2003]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
SubjectProblems with kernel mmap (failing tst-mmap-eofsync in glibc on parisc)
From
Date
This test essentially opens a file (via open(2)), writes something,
opens it via a mmaped file object *read only* (via fopen(...,"rm)) reads
what was writtent, writes some more and reads it via the mmaped file
object.

This last read fails to get the data on parisc. The problem is that our
CPU cache is virtually indexed, and the page the write is storing the
data to (in the buffer cache) and the page it is mmapped to have the
same physical, but different virtual addresses. We need the write() to
trigger a cache update via flush_dcache_page to get the virtually
indexed cache in sync.

The reason this doesn't happen is because the mapping is not on the
mmap_shared list that flush_dcache_page() updates.

And the reason it's not on the correct list is because there's a check
in mm/mmap.c:do_mmap_pgoff() that drops the VM_SHARED flag on the
mapping if the file wasn't opened for writing (about line 541).

Semantically, it seems that whether the mmaping sees a write or not on a
different descriptor shouldn't depend on whether the underlying file was
opened read only or read write, so I think the glibc test is correct,
and we should keep the VM_SHARED flag even if the underlying file was
opened read only.

The patch is attached (and makes the test pass on parisc).

Comments?

James

===== mm/mmap.c 1.89 vs edited =====
--- 1.89/mm/mmap.c Thu Jul 10 21:46:52 2003
+++ edited/mm/mmap.c Fri Aug 22 09:36:32 2003
@@ -539,7 +539,7 @@

vm_flags |= VM_SHARED | VM_MAYSHARE;
if (!(file->f_mode & FMODE_WRITE))
- vm_flags &= ~(VM_MAYWRITE | VM_SHARED);
+ vm_flags &= ~VM_MAYWRITE;

/* fall through */
case MAP_PRIVATE:
\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.091 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site