Re: 2.4.0-test10-pre3:Oops in mm/filemap.c:filemap_write_pa

From: Trond Myklebust (trond.myklebust@fys.uio.no)
Date: Fri Oct 20 2000 - 14:24:58 EST


>>>>> " " == Alexander Viro <viro@math.psu.edu> writes:

> 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.

Even so, you want to reread it. When I said automatically msync(), I
meant 'schedule a write of what has changed and then do whatever you
need to do to get the page reread'. (You explicitly asked for
semantics, not an implementation)

> 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.

That's because under NFS you don't have a cache consistency
protocol. Nothing tells you that the file/directory has changed and
that you have to resync your cache. Instead, you have to infer it from
the fact that some operation has returned file attributes that are
screwy.
In addition you may want to force a reread, because some operation
just changed a directory on the server, and you don't know what else
changed beforehand.

> 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.

The issue is not about removing pages. It's about forcing a reread of
the cached data from the server. Removing the actual pages from the
cache has so far been the only race-free method for doing this (since
pre-2.2.x at least) while ensuring that at least generic 'read',
'readdir' and 'write' work as expected.
Yes it screws up mmap() and should be fixed but without breaking what
little that works please.

As for simply settling for a self-consistent mmap() rather than
tackling the problem of rereading; the main crime is that you're
rendering file locking unusable.
Locking is the case in which you have to issue a guarantee that the
cache is consistent between client and server within the area covered
by the lock. In all other cases you *could* get away with the partial
cache invalidation implementation by arguing that there no consistency
guarantees inherent in the protocol.

Cheers,
  Trond
-
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/



This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:17 EST