lkml.org 
[lkml]   [2008]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 08 of 11] anon-vma-rwsem


    On Wed, 7 May 2008, Andrew Morton wrote:
    >
    > Now, if we need to take both anon_vma->lock AND i_mmap_lock in the newly
    > added mm_lock() thing and we also take both those locks at the same time in
    > regular code, we're probably screwed.

    No, just use the normal static ordering for that case: one type of lock
    goes before the other kind. If those locks nest in regular code, you have
    to do that *anyway*.

    The code that can take many locks, will have to get the global lock *and*
    order the types, but that's still trivial. It's something like

    spin_lock(&global_lock);
    for (vma = mm->mmap; vma; vma = vma->vm_next) {
    if (vma->anon_vma)
    spin_lock(&vma->anon_vma->lock);
    }
    for (vma = mm->mmap; vma; vma = vma->vm_next) {
    if (!vma->anon_vma && vma->vm_file && vma->vm_file->f_mapping)
    spin_lock(&vma->vm_file->f_mapping->i_mmap_lock);
    }
    spin_unlock(&global_lock);

    and now everybody follows the rule that "anon_vma->lock" precedes
    "i_mmap_lock". So there can be no ABBA deadlock between the normal users
    and the many-locks version, and there can be no ABBA deadlock between
    many-locks-takers because they use the global_lock to serialize.

    This really isn't rocket science, guys.

    (I really hope and believe that they don't nest anyway, and that you can
    just use a single for-loop for the many-lock case)

    Linus


    \
     
     \ /
      Last update: 2008-05-08 01:23    [W:4.154 / U:0.056 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site