[lkml]   [2008]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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

    for (vma = mm->mmap; vma; vma = vma->vm_next) {
    if (vma->anon_vma)
    for (vma = mm->mmap; vma; vma = vma->vm_next) {
    if (!vma->anon_vma && vma->vm_file && vma->vm_file->f_mapping)

    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)


     \ /
      Last update: 2008-05-08 01:23    [W:0.023 / U:7.928 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site