Re: linux 4.1-rc7 deadlock

[Prarit Bhargava]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/