Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752959AbbFKWP6 (ORCPT ); Thu, 11 Jun 2015 18:15:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48602 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750750AbbFKWP4 (ORCPT ); Thu, 11 Jun 2015 18:15:56 -0400 Message-ID: <557A089A.3090202@redhat.com> Date: Thu, 11 Jun 2015 18:15:54 -0400 From: Prarit Bhargava User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131028 Thunderbird/17.0.10 MIME-Version: 1.0 To: Hugh Dickins CC: Morten Stevens , Daniel Wagner , Dave Chinner , Eric Paris , Eric Sandeen , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: linux 4.1-rc7 deadlock References: <5576D3E7.40302@fedoraproject.org> <5576F3DA.7000106@monom.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3497 Lines: 90 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 : >>> 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 > Reported-by: Daniel Wagner > Reported-by: Morten Stevens > Not-Yet-Signed-off-by: Hugh Dickins > --- > > 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 P. > if (IS_ERR(file)) > return PTR_ERR(file); > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/