linux-kernel - Re: [Bug #15805] reiserfs locking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Jul 2010 10:24:28 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Maciej Rutecki <maciej.rutecki@...il.com>,
	Alexander Beregalov <a.beregalov@...il.com>,
	Alexander Viro <viro@....linux.org.uk>
Subject: Re: [Bug #15805] reiserfs locking

On Sat, Jul 10, 2010 at 12:06 AM, Ingo Molnar <mingo@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/