On 06/11/2015 04:06 PM, Hugh Dickins wrote: > On Tue, 9 Jun 2015, Morten Stevens wrote: >> 2015-06-09 16:10 GMT+02:00 Daniel Wagner <wagi@xxxxxxxxx>: >>> On 06/09/2015 01:54 PM, Morten Stevens wrote: >>>> [ 28.193327] Possible unsafe locking scenario: >>>> >>>> [ 28.194297] CPU0 CPU1 >>>> [ 28.194774] ---- ---- >>>> [ 28.195254] lock(&mm->mmap_sem); >>>> [ 28.195709] lock(&xfs_dir_ilock_class); >>>> [ 28.196174] lock(&mm->mmap_sem); >>>> [ 28.196654] lock(&isec->lock); >>>> [ 28.197108] >>> >>> [...] >>> >>>> Any ideas? >>> >>> I think you hit the same problem many have already reported: >>> >>> https://lkml.org/lkml/2015/3/30/594 >> >> Yes, that sounds very likely. But that was about 1 month ago, so I >> thought that it has been fixed in the last weeks? > > It's not likely to get fixed without Cc'ing the right people. > > This appears to be the same as Prarit reported to linux-mm on > 2014/09/10. Dave Chinner thinks it's a shmem bug, I disagree, > but I am hopeful that it can be easily fixed at the shmem end. > > Here's the patch I suggested nine months ago: but got no feedback, > so it remains Not-Yet-Signed-off-by. Please, if you find this works > (and does not just delay the lockdep conflict until a little later), > do let me know, then I can add some Tested-bys and send it to Linus. > > mm: shmem_zero_setup skip security check and lockdep conflict with XFS > > It appears that, at some point last year, XFS made directory handling > changes which bring it into lockdep conflict with shmem_zero_setup(): > it is surprising that mmap() can clone an inode while holding mmap_sem, > but that has been so for many years. > > Since those few lockdep traces that I've seen all implicated selinux, > I'm hoping that we can use the __shmem_file_setup(,,,S_PRIVATE) which > v3.13's commit c7277090927a ("security: shmem: implement kernel private > shmem inodes") introduced to avoid LSM checks on kernel-internal inodes: > the mmap("/dev/zero") cloned inode is indeed a kernel-internal detail. > > This also covers the !CONFIG_SHMEM use of ramfs to support /dev/zero > (and MAP_SHARED|MAP_ANONYMOUS). I thought there were also drivers > which cloned inode in mmap(), but if so, I cannot locate them now. > > Reported-by: Prarit Bhargava <prarit@xxxxxxxxxx> > Reported-by: Daniel Wagner <wagi@xxxxxxxxx> > Reported-by: Morten Stevens <mstevens@xxxxxxxxxxxxxxxxx> > Not-Yet-Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx> > --- > > mm/shmem.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- 4.1-rc7/mm/shmem.c 2015-04-26 19:16:31.352191298 -0700 > +++ linux/mm/shmem.c 2015-06-11 11:08:21.042745594 -0700 > @@ -3401,7 +3401,7 @@ int shmem_zero_setup(struct vm_area_stru > struct file *file; > loff_t size = vma->vm_end - vma->vm_start; > > - file = shmem_file_setup("dev/zero", size, vma->vm_flags); > + file = __shmem_file_setup("dev/zero", size, vma->vm_flags, S_PRIVATE); Perhaps, file = shmem_kernel_file_setup("dev/zero", size, vma->vm_flags) ? Tested-by: Prarit Bhargava <prarit@xxxxxxxxxx> P. > if (IS_ERR(file)) > return PTR_ERR(file); > > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>