lkml.org 
[lkml]   [2010]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [Bug #15805] reiserfs locking
    From
    On Sat, Jul 10, 2010 at 12:06 AM, Ingo Molnar <mingo@elte.hu> wrote:
    >
    > Since it's a reproducible deadlock maybe the fix should go upstream faster
    > than v2.6.36?

    As far as I know, it's only a lockdep warning, not an actual deadlock.
    And it's in a class of lockdep warnings that we've had for a long
    time, and has never actually triggered as a read deadlock afaik.

    I also don't think it's a new warning - or at least I don't see why it
    would have started triggering after 2.6.34.

    My preferred fix in many ways would be to make the locking in the VM
    layer less incestuous. For example, we could fairly easily move the
    final

    if (vma->vm_file)
    fput(vma->vm_file);

    outside the actual mmap_sem lock (well, "fairly easily" here means
    keeping the list of free'd vmas around for longer, probably in the
    task_struct thing, and then replacing all the
    "up_write(&mm->mmap_sem)" things with a "unlock_mm(mm)" looking
    something like

    static void unlock_mm(struct mm_struct *mm)
    {
    struct vm_area_struct *vma_list = current->vma_to_free;
    if (vma_list)
    current->vma_to_free = NULL;
    up_write(&mm->mmap_sem);
    while (vma_list) {
    struct vm_area_struct *vma = vma_list;
    vma_list = vma_list->next;
    fput(vma_list->vm_file);
    kmem_cache_free(vm_area_cachep, vma);
    }
    }

    which would fairly trivially delay the actual 'fput()' to after we
    hold no locks.

    I dunno if it's really worth it, but it doesn't look all that
    complicated, and it would avoid at least _some_ lock dependencies.

    Linus

    Linus


    \
     
     \ /
      Last update: 2010-07-10 19:27    [W:2.962 / U:0.212 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site