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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
