All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junil Lee <junil0814.lee@lge.com>
To: <minchan@kernel.org>, <ngupta@vflare.org>
Cc: sergey.senozhatsky.work@gmail.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Junil Lee <junil0814.lee@lge.com>
Subject: [PATCH] zsmalloc: fix migrate_zspage-zs_free race condition
Date: Fri, 15 Jan 2016 09:36:24 +0900	[thread overview]
Message-ID: <1452818184-2994-1-git-send-email-junil0814.lee@lge.com> (raw)

To prevent unlock at the not correct situation, tagging the new obj to
assure lock in migrate_zspage() before right unlock path.

Two functions are in race condition by tag which set 1 on last bit of
obj, however unlock succrently when update new obj to handle before call
unpin_tag() which is right unlock path.

summarize this problem by call flow as below:

		CPU0								CPU1
migrate_zspage
find_alloced_obj()
	trypin_tag() -- obj |= HANDLE_PIN_BIT
obj_malloc() -- new obj is not set			zs_free
record_obj() -- unlock and break sync		pin_tag() -- get lock
unpin_tag()

Signed-off-by: Junil Lee <junil0814.lee@lge.com>
---
 mm/zsmalloc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index e7414ce..bb459ef 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1635,6 +1635,7 @@ static int migrate_zspage(struct zs_pool *pool, struct size_class *class,
 		free_obj = obj_malloc(d_page, class, handle);
 		zs_object_copy(free_obj, used_obj, class);
 		index++;
+		free_obj |= BIT(HANDLE_PIN_BIT);
 		record_obj(handle, free_obj);
 		unpin_tag(handle);
 		obj_free(pool, class, used_obj);
-- 
2.6.2

WARNING: multiple messages have this Message-ID (diff)
From: Junil Lee <junil0814.lee@lge.com>
To: minchan@kernel.org, ngupta@vflare.org
Cc: sergey.senozhatsky.work@gmail.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Junil Lee <junil0814.lee@lge.com>
Subject: [PATCH] zsmalloc: fix migrate_zspage-zs_free race condition
Date: Fri, 15 Jan 2016 09:36:24 +0900	[thread overview]
Message-ID: <1452818184-2994-1-git-send-email-junil0814.lee@lge.com> (raw)

To prevent unlock at the not correct situation, tagging the new obj to
assure lock in migrate_zspage() before right unlock path.

Two functions are in race condition by tag which set 1 on last bit of
obj, however unlock succrently when update new obj to handle before call
unpin_tag() which is right unlock path.

summarize this problem by call flow as below:

		CPU0								CPU1
migrate_zspage
find_alloced_obj()
	trypin_tag() -- obj |= HANDLE_PIN_BIT
obj_malloc() -- new obj is not set			zs_free
record_obj() -- unlock and break sync		pin_tag() -- get lock
unpin_tag()

Signed-off-by: Junil Lee <junil0814.lee@lge.com>
---
 mm/zsmalloc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index e7414ce..bb459ef 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1635,6 +1635,7 @@ static int migrate_zspage(struct zs_pool *pool, struct size_class *class,
 		free_obj = obj_malloc(d_page, class, handle);
 		zs_object_copy(free_obj, used_obj, class);
 		index++;
+		free_obj |= BIT(HANDLE_PIN_BIT);
 		record_obj(handle, free_obj);
 		unpin_tag(handle);
 		obj_free(pool, class, used_obj);
-- 
2.6.2

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

             reply	other threads:[~2016-01-15  0:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15  0:36 Junil Lee [this message]
2016-01-15  0:36 ` [PATCH] zsmalloc: fix migrate_zspage-zs_free race condition Junil Lee
2016-01-15  2:35 ` Minchan Kim
2016-01-15  2:35   ` Minchan Kim
2016-01-15  3:27   ` Sergey Senozhatsky
2016-01-15  3:27     ` Sergey Senozhatsky
2016-01-15  3:30     ` Sergey Senozhatsky
2016-01-15  3:30       ` Sergey Senozhatsky
2016-01-15  4:49     ` Minchan Kim
2016-01-15  4:49       ` Minchan Kim
2016-01-15  5:07       ` Sergey Senozhatsky
2016-01-15  5:07         ` Sergey Senozhatsky
2016-01-19 15:47         ` Russell Knize
2016-01-20  7:00           ` Minchan Kim
2016-01-20  7:00             ` Minchan Kim
2016-01-20 15:21             ` Russell Knize
2016-01-20 15:21               ` Russell Knize
2016-01-15  5:05   ` Minchan Kim
2016-01-15  5:05     ` Minchan Kim

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=1452818184-2994-1-git-send-email-junil0814.lee@lge.com \
    --to=junil0814.lee@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    /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.