On Tue, Aug 09, 2005 at 05:49:43PM +0300, Pekka Enberg wrote: > 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. We already have OCFS2 in -mm that does similar things. I think we need to solve this in common code before either of them can be merged. -- Linux-cluster@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/linux-cluster
