Messages in this thread | | | Date | Fri, 20 Oct 2000 14:37:25 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: 2.4.0-test10-pre3:Oops in mm/filemap.c:filemap_write_pa |
| |
On Fri, 20 Oct 2000, Trond Myklebust wrote:
> For the general case of the page cache I think we can keep them quite > simple: > > + We do in any case want to drop all pages that are unreferenced. (The > reason for flushing may be that the file size has changed.) > > + For pages that are referenced (and unlocked) we would like to force > them to get read in anew ASAP. How this is done in practice is > irrelevant as far as NFS is concerned provided that we don't sleep on > any I/O while in nfs_zap_caches()/invalidate_inode_pages(). > > The lower level stuff can and will sort out the business of flushing > out pending writebacks that conflict with the read, so that isn't a > problem for the VFS/VM. > > The problem lies with writes that haven't yet been msync()ed (and > hence do not have writebacks). For shared mappings, one should perhaps > schedule an automatic msync() of the dirty pages (???). For private > mappings, perhaps the best thing would be to defer the read?
Again, consider the case when two processes share the mapping. Process A has page faulted in. Page is invalidated. Process B tries to access the same page. If you leave it in page tables of A you _MUST_ leave it in cache. Period. Otherwise A and B will have different instances of the page.
It's not about writebacks. If you map something with MAP_SHARED and fork() afterwards you _MUST_ have the same data at the address returned by mmap() until one of the processes unmaps the thing.
And rereading the thing might be tolerable _only_ if there is another client that had changed the file. Even if you msync() everything, you have to deal with plain and boring memory modifications done by a process that did that bloody mmap(). If they happen while you are reading the data from server - too fscking bad, you'ld better have a good excuse for destroying the data. write() from another client _is_ a good excuse. But from my reading of fs/nfs/* it looks like we do that (cache invalidation) left, right and center in cases that have nothing to another clients.
IOW, I think that invalidate_inode_pages() is bogus. There is only one situation when we have a right to remove page from pagecache - when it is not mapped anywhere.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |