[PATCH] kmemleak: Protect the seq start/next/stop sequence by rcu_read_lock()

[PATCH] kmemleak: Protect the seq start/next/stop sequence by rcu_read_lock()

[Catalin Marinas]

Objects passed to kmemleak_seq_next() have an incremented reference
count (hence not freed) but they may point via object_list.next to
other freed objects. To avoid this, the whole start/next/stop sequence
must be protected by rcu_read_lock().

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---

This is a fix for bug #13761 raised on bugzilla.kernel.org.

 mm/kmemleak.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 5aabd41..4872673 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1217,7 +1217,6 @@ static void *kmemleak_seq_start(struct seq_file *seq, loff_t *pos)
 	}
 	object = NULL;
 out:
-	rcu_read_unlock();
 	return object;
 }
 
@@ -1233,13 +1232,11 @@ static void *kmemleak_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 
 	++(*pos);
 
-	rcu_read_lock();
 	list_for_each_continue_rcu(n, &object_list) {
 		next_obj = list_entry(n, struct kmemleak_object, object_list);
 		if (get_object(next_obj))
 			break;
 	}
-	rcu_read_unlock();
 
 	put_object(prev_obj);
 	return next_obj;
@@ -1255,6 +1252,7 @@ static void kmemleak_seq_stop(struct seq_file *seq, void *v)
 		 * kmemleak_seq_start may return ERR_PTR if the scan_mutex
 		 * waiting was interrupted, so only release it if !IS_ERR.
 		 */
+		rcu_read_unlock();
 		mutex_unlock(&scan_mutex);
 		if (v)
 			put_object(v);

Re: [PATCH] kmemleak: Protect the seq start/next/stop sequence by rcu_read_lock()

[Catalin Marinas]

On Wed, 2009-07-29 at 17:00 -0700, Andrew Morton wrote:
> On Wed, 29 Jul 2009 16:26:57 +0100
> Catalin Marinas <catalin.marinas@arm.com> wrote:
> 
> > Objects passed to kmemleak_seq_next() have an incremented reference
> > count (hence not freed) but they may point via object_list.next to
> > other freed objects. To avoid this, the whole start/next/stop sequence
> > must be protected by rcu_read_lock().
> > 
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > ---
> > 
> > This is a fix for bug #13761 in buzilla.kernel.org. If there are no
> > objections, please apply it before 2.6.31. Thanks.
> 
> Administrivia:
> 
> When referencing a bugzilla report, please quote the full URL within
> the changelog (not after the ^---$).  I use:
> 
> 	Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13761
> 
> This is because people ocassionally troll the commit logs, closing off
> bugzilla reports.  Using a standardised format simplifies that job, and
> makes it more reliable.
> 
> Also, it's nice to give the original bug reporter a Reported-by: in the
> changelog.  As a little thank-you, and so they know what's going on.

Yes, I agree. Thanks for adjusting these in the -mm tree patch.

-- 
Catalin

Re: [PATCH] kmemleak: Protect the seq start/next/stop sequence by rcu_read_lock()

[Andrew Morton]

On Wed, 29 Jul 2009 16:26:57 +0100
Catalin Marinas <catalin.marinas@arm.com> wrote:

> Objects passed to kmemleak_seq_next() have an incremented reference
> count (hence not freed) but they may point via object_list.next to
> other freed objects. To avoid this, the whole start/next/stop sequence
> must be protected by rcu_read_lock().
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> 
> This is a fix for bug #13761 in buzilla.kernel.org. If there are no
> objections, please apply it before 2.6.31. Thanks.

Administrivia:

When referencing a bugzilla report, please quote the full URL within
the changelog (not after the ^---$).  I use:

	Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13761

This is because people ocassionally troll the commit logs, closing off
bugzilla reports.  Using a standardised format simplifies that job, and
makes it more reliable.

Also, it's nice to give the original bug reporter a Reported-by: in the
changelog.  As a little thank-you, and so they know what's going on.

[PATCH] kmemleak: Protect the seq start/next/stop sequence by rcu_read_lock()

[Catalin Marinas]

Objects passed to kmemleak_seq_next() have an incremented reference
count (hence not freed) but they may point via object_list.next to
other freed objects. To avoid this, the whole start/next/stop sequence
must be protected by rcu_read_lock().

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---

This is a fix for bug #13761 in buzilla.kernel.org. If there are no
objections, please apply it before 2.6.31. Thanks.

 mm/kmemleak.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 5aabd41..4872673 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1217,7 +1217,6 @@ static void *kmemleak_seq_start(struct seq_file *seq, loff_t *pos)
 	}
 	object = NULL;
 out:
-	rcu_read_unlock();
 	return object;
 }
 
@@ -1233,13 +1232,11 @@ static void *kmemleak_seq_next(struct seq_file *seq, void *v, loff_t *pos)
 
 	++(*pos);
 
-	rcu_read_lock();
 	list_for_each_continue_rcu(n, &object_list) {
 		next_obj = list_entry(n, struct kmemleak_object, object_list);
 		if (get_object(next_obj))
 			break;
 	}
-	rcu_read_unlock();
 
 	put_object(prev_obj);
 	return next_obj;
@@ -1255,6 +1252,7 @@ static void kmemleak_seq_stop(struct seq_file *seq, void *v)
 		 * kmemleak_seq_start may return ERR_PTR if the scan_mutex
 		 * waiting was interrupted, so only release it if !IS_ERR.
 		 */
+		rcu_read_unlock();
 		mutex_unlock(&scan_mutex);
 		if (v)
 			put_object(v);