Messages in this thread | | | From | KOSAKI Motohiro <> | Subject | Re: NFS lockdep lock misordering mmap_sem<->i_mutex_key with 2.6.32-git1 | Date | Wed, 16 Dec 2009 09:06:12 +0900 (JST) |
| |
> On Tue, Dec 15, 2009 at 10:21:34PM +0000, Al Viro wrote: > > On Mon, Dec 07, 2009 at 02:20:09PM +0100, Andi Kleen wrote: > > > > nfs_readdir > > > > nfs_do_filldir > > > > filldir > > > > copy_to_user > > > > [page_fault] [grab mmap_sem] > > > > > > > > sys_mmap [grab mmap_sem] > > > > do_mmap_pgoff > > > > mmap_region > > > > nfs_file_mmap > > > > nfs_revalidate_mapping > > > > nfs_invalidate_mapping [grab i_mutex] > > > > > > > > I guess recent lockdep improvement find old bug. > > > > > > Thanks for the analysis. > > > > > > I guess should never do copy_*_user while holding i_mutex? There might > > > be lots of cases like that. > > > > No. mmap_sem inside i_mutex is the normal order; NFS mmap is doing the > > wrong thing here. Note that readdir() vs. NFS (file-only, thankfully ;-) > > mmap() is a non-issue; NFS mmap() vs. write() is much more interesting. > > I see. > > > > > Again, a lot of mm/* code expects i_mutex, then mmap_sem order. It's not > > just readdir(). > > I suppose an easy workaround would be to not revalidate in mmap, > because open should have already done that? > > Very lightly tested RFC patch attached. > > -Andi > > --- > > NFS: don't revalidate in mmap > > nfs_revalidate_mapping takes i_mutex, but mmap already has mmap_sem > hold and taking i_mutex inside mmap_sem is not allowed by the VFS. > > So don't revalidate on mmap time and trust it has been already done. > > Signed-off-by: Andi Kleen <ak@linux.intel.com>
afaik, no revalidate mean "I don't mind the file was already removed at server, I only care client handle".
What's happen if we mmap removed file?
| |