lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 16 Dec 2009 09:06:12 +0900 (JST) From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com> To: Andi Kleen <andi@...stfloor.org> Cc: kosaki.motohiro@...fujitsu.com, Al Viro <viro@...IV.linux.org.uk>, linux-kernel@...r.kernel.org, Trond.Myklebust@...app.com Subject: Re: NFS lockdep lock misordering mmap_sem<->i_mutex_key with 2.6.32-git1 > 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@...ux.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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists