linux-kernel - Re: [PATCH 2 of 3] mm_take_all

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20080605164421.GG15502@duo.random>
Date:	Thu, 5 Jun 2008 18:44:21 +0200
From:	Andrea Arcangeli <andrea@...ranet.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <clameter@....com>,
	Jack Steiner <steiner@....com>, Robin Holt <holt@....com>,
	Nick Piggin <npiggin@...e.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>, kvm@...r.kernel.org,
	Kanoj Sarcar <kanojsarcar@...oo.com>,
	Roland Dreier <rdreier@...co.com>,
	Steve Wise <swise@...ngridcomputing.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Avi Kivity <avi@...ranet.com>, linux-mm@...ck.org,
	general@...ts.openfabrics.org, Hugh Dickins <hugh@...itas.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Anthony Liguori <aliguori@...ibm.com>,
	Chris Wright <chrisw@...hat.com>,
	Marcelo Tosatti <marcelo@...ck.org>,
	Eric Dumazet <dada1@...mosbay.com>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Izik Eidus <izike@...ranet.com>, Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 2 of 3] mm_take_all_locks

On Thu, Jun 05, 2008 at 09:15:41AM -0700, Linus Torvalds wrote:
> 
> Just a small comment fix.
> 
> On Thu, 5 Jun 2008, Andrea Arcangeli wrote:
> > +		/*
> > +		 * AS_MM_ALL_LOCKS can't change from under us because
> > +		 * we hold the global_mm_spinlock.
> 
> There's no global_mm_spinlock, you mean the 'mm_all_locks_mutex'.
> 
> (There was at least one other case where you had that comment issue).

From: Andrea Arcangeli <andrea@...ranet.com>

Indeed, I meant mm_all_locks_mutex, this will fix it, or if you prefer
a resubmit of the 2/3 let me know. Thanks!

Signed-off-by: Andrea Arcangeli <andrea@...ranet.com>
---

diff -r 082f312bc682 mm/mmap.c
--- a/mm/mmap.c	Thu Jun 05 17:30:17 2008 +0200
+++ b/mm/mmap.c	Thu Jun 05 18:40:23 2008 +0200
@@ -2263,7 +2263,7 @@ static void vm_lock_anon_vma(struct anon
 	if (!test_bit(0, (unsigned long *) &anon_vma->head.next)) {
 		/*
 		 * The LSB of head.next can't change from under us
-		 * because we hold the global_mm_spinlock.
+		 * because we hold the mm_all_locks_mutex.
 		 */
 		spin_lock(&anon_vma->lock);
 		/*
@@ -2286,11 +2286,11 @@ static void vm_lock_mapping(struct addre
 	if (!test_bit(AS_MM_ALL_LOCKS, &mapping->flags)) {
 		/*
 		 * AS_MM_ALL_LOCKS can't change from under us because
-		 * we hold the global_mm_spinlock.
+		 * we hold the mm_all_locks_mutex.
 		 *
 		 * Operations on ->flags have to be atomic because
 		 * even if AS_MM_ALL_LOCKS is stable thanks to the
-		 * global_mm_spinlock, there may be other cpus
+		 * mm_all_locks_mutex, there may be other cpus
 		 * changing other bitflags in parallel to us.
 		 */
 		if (test_and_set_bit(AS_MM_ALL_LOCKS, &mapping->flags))
@@ -2362,7 +2362,7 @@ static void vm_unlock_anon_vma(struct an
 	if (test_bit(0, (unsigned long *) &anon_vma->head.next)) {
 		/*
 		 * The LSB of head.next can't change to 0 from under
-		 * us because we hold the global_mm_spinlock.
+		 * us because we hold the mm_all_locks_mutex.
 		 *
 		 * We must however clear the bitflag before unlocking
 		 * the vma so the users using the anon_vma->head will
@@ -2384,7 +2384,7 @@ static void vm_unlock_mapping(struct add
 	if (test_bit(AS_MM_ALL_LOCKS, &mapping->flags)) {
 		/*
 		 * AS_MM_ALL_LOCKS can't change to 0 from under us
-		 * because we hold the global_mm_spinlock.
+		 * because we hold the mm_all_locks_mutex.
 		 */
 		spin_unlock(&mapping->i_mmap_lock);
 		if (!test_and_clear_bit(AS_MM_ALL_LOCKS,
--
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/