Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1706480

Re: [RFC v5 05/11] mm: fix lock dependency against mapping->i_mmap_rwsem

Path csiph.com!news.redatomik.org!aioe.org!bofh.it!news.nic.it!robomod
From Laurent Dufour <ldufour@linux.vnet.ibm.com>
Newsgroups linux.kernel
Subject Re: [RFC v5 05/11] mm: fix lock dependency against mapping->i_mmap_rwsem
Date Tue, 08 Aug 2017 14:30:02 +0200
Message-ID <ucbO2-8kG-11@gated-at.bofh.it> (permalink)
References <tT3Hj-3lN-3@gated-at.bofh.it> <tT3Hj-3lN-1@gated-at.bofh.it> <ucaIi-7zl-29@gated-at.bofh.it>
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version 1.0
Content-Type text/plain; charset=windows-1252
Content-Language en-US
Content-Transfer-Encoding 7bit
X-Tm-As-Gconf 00
X-Cbid 17080812-0020-0000-0000-000003AC40D6
X-Ibm-Av-Detection SAVI=unused REMOTE=unused XFE=unused
X-Cbparentid 17080812-0021-0000-0000-000042397836
X-Proofpoint-Virus-Version vendor=fsecure engine=2.50.10432:,, definitions=2017-08-08_04:,, signatures=0
X-Proofpoint-Spam-Details rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708080196
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 80
Organization linux.* mail to news gateway
X-Original-Cc linux-kernel@vger.kernel.org, linux-mm@kvack.org, haren@linux.vnet.ibm.com, npiggin@gmail.com, bsingharora@gmail.com, Tim Chen <tim.c.chen@linux.intel.com>
X-Original-Date Tue, 8 Aug 2017 14:20:23 +0200
X-Original-Message-ID <78d903c4-6e9f-e049-de60-6d1ccb45ff92@linux.vnet.ibm.com>
X-Original-References <1497635555-25679-1-git-send-email-ldufour@linux.vnet.ibm.com> <1497635555-25679-6-git-send-email-ldufour@linux.vnet.ibm.com> <564749a2-a729-b927-7707-1cad897c418a@linux.vnet.ibm.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1706480

Show key headers only | View raw


On 08/08/2017 13:17, Anshuman Khandual wrote:
> On 06/16/2017 11:22 PM, Laurent Dufour wrote:
>> kworker/32:1/819 is trying to acquire lock:
>>  (&vma->vm_sequence){+.+...}, at: [<c0000000002f20e0>]
>> zap_page_range_single+0xd0/0x1a0
>>
>> but task is already holding lock:
>>  (&mapping->i_mmap_rwsem){++++..}, at: [<c0000000002f229c>]
>> unmap_mapping_range+0x7c/0x160
>>
>> which lock already depends on the new lock.
>>
>> the existing dependency chain (in reverse order) is:
>>
>> -> #2 (&mapping->i_mmap_rwsem){++++..}:
>>        down_write+0x84/0x130
>>        __vma_adjust+0x1f4/0xa80
>>        __split_vma.isra.2+0x174/0x290
>>        do_munmap+0x13c/0x4e0
>>        vm_munmap+0x64/0xb0
>>        elf_map+0x11c/0x130
>>        load_elf_binary+0x6f0/0x15f0
>>        search_binary_handler+0xe0/0x2a0
>>        do_execveat_common.isra.14+0x7fc/0xbe0
>>        call_usermodehelper_exec_async+0x14c/0x1d0
>>        ret_from_kernel_thread+0x5c/0x68
>>
>> -> #1 (&vma->vm_sequence/1){+.+...}:
>>        __vma_adjust+0x124/0xa80
>>        __split_vma.isra.2+0x174/0x290
>>        do_munmap+0x13c/0x4e0
>>        vm_munmap+0x64/0xb0
>>        elf_map+0x11c/0x130
>>        load_elf_binary+0x6f0/0x15f0
>>        search_binary_handler+0xe0/0x2a0
>>        do_execveat_common.isra.14+0x7fc/0xbe0
>>        call_usermodehelper_exec_async+0x14c/0x1d0
>>        ret_from_kernel_thread+0x5c/0x68
>>
>> -> #0 (&vma->vm_sequence){+.+...}:
>>        lock_acquire+0xf4/0x310
>>        unmap_page_range+0xcc/0xfa0
>>        zap_page_range_single+0xd0/0x1a0
>>        unmap_mapping_range+0x138/0x160
>>        truncate_pagecache+0x50/0xa0
>>        put_aio_ring_file+0x48/0xb0
>>        aio_free_ring+0x40/0x1b0
>>        free_ioctx+0x38/0xc0
>>        process_one_work+0x2cc/0x8a0
>>        worker_thread+0xac/0x580
>>        kthread+0x164/0x1b0
>>        ret_from_kernel_thread+0x5c/0x68
>>
>> other info that might help us debug this:
>>
>> Chain exists of:
>>   &vma->vm_sequence --> &vma->vm_sequence/1 --> &mapping->i_mmap_rwsem
>>
>>  Possible unsafe locking scenario:
>>
>>        CPU0                    CPU1
>>        ----                    ----
>>   lock(&mapping->i_mmap_rwsem);
>>                                lock(&vma->vm_sequence/1);
>>                                lock(&mapping->i_mmap_rwsem);
>>   lock(&vma->vm_sequence);
>>
>>  *** DEADLOCK ***
>>
>> To fix that we must grab the vm_sequence lock after any mapping one in
>> __vma_adjust().
>>
>> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
> 
> Should not this be folded back into the previous patch ? It fixes an
> issue introduced by the previous one.

This is an option, but the previous one was signed by Peter, and I'd prefer
to keep his unchanged and add this new one to fix that.
Again this is to ease the review.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC v5 05/11] mm: fix lock dependency against  mapping->i_mmap_rwsem Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-08-08 13:20 +0200
  Re: [RFC v5 05/11] mm: fix lock dependency against  mapping->i_mmap_rwsem Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-08-08 14:30 +0200
    Re: [RFC v5 05/11] mm: fix lock dependency against  mapping->i_mmap_rwsem Jan Kara <jack@suse.cz> - 2017-08-08 14:50 +0200
      Re: [RFC v5 05/11] mm: fix lock dependency against  mapping->i_mmap_rwsem Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-08-08 15:10 +0200
    Re: [RFC v5 05/11] mm: fix lock dependency against  mapping->i_mmap_rwsem Peter Zijlstra <peterz@infradead.org> - 2017-08-08 15:20 +0200
      Re: [RFC v5 05/11] mm: fix lock dependency against  mapping->i_mmap_rwsem Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-08-08 15:40 +0200

csiph-web