All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinayak Menon <vinmenon@codeaurora.org>
To: catalin.marinas@arm.com
Cc: linux-mm@kvack.org, Vinayak Menon <vinmenon@codeaurora.org>
Subject: [PATCH] mm: kmemleak: wait for scan completion before disabling free
Date: Mon, 26 Mar 2018 16:53:49 +0530	[thread overview]
Message-ID: <1522063429-18992-1-git-send-email-vinmenon@codeaurora.org> (raw)

A crash is observed when kmemleak_scan accesses the
object->pointer, likely due to the following race.

TASK A             TASK B                     TASK C
kmemleak_write
 (with "scan" and
 NOT "scan=on")
kmemleak_scan()
                   create_object
                   kmem_cache_alloc fails
                   kmemleak_disable
                   kmemleak_do_cleanup
                   kmemleak_free_enabled = 0
                                              kfree
                                              kmemleak_free bails out
                                               (kmemleak_free_enabled is 0)
                                              slub frees object->pointer
update_checksum
crash - object->pointer
 freed (DEBUG_PAGEALLOC)

kmemleak_do_cleanup waits for the scan thread to complete, but not for
direct call to kmemleak_scan via kmemleak_write. So add a wait for
kmemleak_scan completion before disabling kmemleak_free.

Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
---
 mm/kmemleak.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 8b9afc5..aa9c84b 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1931,12 +1931,15 @@ static void kmemleak_do_cleanup(struct work_struct *work)
 {
 	stop_scan_thread();
 
+	mutex_lock(&scan_mutex);
 	/*
-	 * Once the scan thread has stopped, it is safe to no longer track
-	 * object freeing. Ordering of the scan thread stopping and the memory
-	 * accesses below is guaranteed by the kthread_stop() function.
+	 * Once it is made sure that kmemleak_scan has stopped, it is safe to no
+	 * longer track object freeing. Ordering of the scan thread stopping and
+	 * the memory accesses below is guaranteed by the kthread_stop()
+	 * function.
 	 */
 	kmemleak_free_enabled = 0;
+	mutex_unlock(&scan_mutex);
 
 	if (!kmemleak_found_leaks)
 		__kmemleak_do_cleanup();
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation

             reply	other threads:[~2018-03-26 11:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-26 11:23 Vinayak Menon [this message]
2018-03-26 15:44 ` [PATCH] mm: kmemleak: wait for scan completion before disabling free Catalin Marinas
2018-03-26 19:26   ` Andrew Morton
2018-03-26 19:27     ` Andrew Morton
2018-03-27  5:29     ` Vinayak Menon
2018-03-27 17:49       ` Catalin Marinas
2018-03-28  6:51         ` Vinayak Menon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1522063429-18992-1-git-send-email-vinmenon@codeaurora.org \
    --to=vinmenon@codeaurora.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.