On Mon, 2005-08-08 at 11:32 -0700, Zach Brown wrote: > > Sorry if this is an obvious question but what prevents another thread > > from doing mmap() before we do the second walk and messing up num_gh? > > Nothing, I suspect. OCFS2 has a problem like this, too. It wants a way > for a file system to serialize mmap/munmap/mremap during file IO. Well, > more specifically, it wants to make sure that the locks it acquired at > the start of the IO really cover the buf regions that might fault during > the IO.. mapping activity during the IO can wreck that. In addition, the vma walk will become an unmaintainable mess as soon as someone introduces another mmap() capable fs that needs similar locking. I am not an expert so could someone please explain why this cannot be done with a_ops->prepare_write and friends? Pekka -- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
