On Fri, Jan 08, 2010 at 05:57:27PM -0800, Linus Torvalds wrote: > > > On Sat, 9 Jan 2010, Al Viro wrote: > > > > readdir() is certainly a red herring. > > That's the one that lockdep reports, though. I still don't see why. Afaik, > the only place where NFS gets an inode is nfs_fhget(), and that seems to > do things correctly. Well, sure - it steps on i_mutex-before-mmmap_sem first from ls somewhere and records the ordering for posterity. Then NFS steps into mmap() (on a different inode) and gets conflicting ordering. It would be a false positive if rules for NFS *really* had been different and it could safely grab i_mutex on NFS inodes inside mmap_sem. It can't. The rules really are the same. And readdir is just the earliest case of kernel stepping on mmap_sem while holding *some* i_mutex. write() is another and there i_mutex can very well be the same as in case of mmap(). lockdep doesn't make a distinction (and really, how many paths reinforcing the normal lock ordering would you record?), but if we'd given i_mutex of NFS regular files a class of its own, we'd see a warning with nfs write instead of readdir... -- 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
