On Fri, Jan 08, 2010 at 07:56:24PM -0500, Trond Myklebust wrote: > We cannot call nfs_invalidate_mapping() inside file->f_ops->mmap(), since > this would cause us to grab the inode->i_mutex while already holding the > current->mm->mmap_sem (thus causing a potential ABBA deadlock with the file > write code, which can grab those locks in the opposite order). > > We can fix this situation for the mmap() system call by using the new > mmap_pgoff() callback, which is called prior to taking the > current->mm->mmap_sem mutex. > > We also add ensure that open() invalidates the mapping if the inode data is > stale so that other users of mmap() (mainly the exec and uselib system > calls) get up to date data too. > + status = nfs_revalidate_mapping(inode, file->f_mapping); > + if (status < 0) > + return status; > + > + return generic_file_mmap_pgoff(file, addr, len, prot, flags, pgoff); This is completely bogus. Why do you need i_mutex for that and what the <expletives> does that really prevent? You might wait for a _loong_ time waiting for that mmap_sem, so what is really going on there? -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
