linux-kernel - Re: [PATCH] z3fold: fix possible reclaim races

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]

Date:   Mon, 5 Nov 2018 15:31:59 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Vitaly Wool <vitalywool@...il.com>
Cc:     Linux-MM <linux-mm@...ck.org>, linux-kernel@...r.kernel.org,
        Oleksiy.Avramchenko@...y.com, Guenter Roeck <linux@...ck-us.net>,
        snild@...y.com, Jongseok Kim <ks77sj@...il.com>
Subject: Re: [PATCH] z3fold: fix possible reclaim races

On Mon, 5 Nov 2018 16:22:25 +0100 Vitaly Wool <vitalywool@...il.com> wrote:

> Reclaim and free can race on an object which is basically fine but
> in order for reclaim to be able to  map "freed" object we need to
> encode object length in the handle. handle_to_chunks() is then
> introduced to extract object length from a handle and use it during
> mapping.
> 
> Moreover, to avoid racing on a z3fold "headless" page release, we
> should not try to free that page in z3fold_free() if the reclaim
> bit is set. Also, in the unlikely case of trying to reclaim a page
> being freed, we should not proceed with that page.
> 
> While at it, fix the page accounting in reclaim function.
> 
> This patch supersedes "[PATCH] z3fold: fix reclaim lock-ups".

This conflicts with z3fold-fix-wrong-handling-of-headless-pages.patch,
below.  What should we do?

(I think we're still awaiting your input on this one.  Or I might have
missed an amail.)



From: Jongseok Kim <ks77sj@...il.com>
Subject: mm/z3fold.c: fix wrong handling of headless pages

During the processing of headless pages in z3fold_reclaim_page(), there
was a problem that the zhdr pointed to another page or a page was already
released in z3fold_free().  So, the wrong page is encoded in headless, or
test_bit does not work properly in z3fold_reclaim_page().  This patch
fixed these problems.

Link: http://lkml.kernel.org/r/1530853846-30215-1-git-send-email-ks77sj@gmail.com
Signed-off-by: Jongseok Kim <ks77sj@...il.com>
Cc: Vitaly Wool <vitalywool@...il.com>
Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
---

 mm/z3fold.c |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

--- a/mm/z3fold.c~z3fold-fix-wrong-handling-of-headless-pages
+++ a/mm/z3fold.c
@@ -746,6 +746,9 @@ static void z3fold_free(struct z3fold_po
 	}
 
 	if (bud == HEADLESS) {
+		if (test_bit(UNDER_RECLAIM, &page->private))
+			return;
+
 		spin_lock(&pool->lock);
 		list_del(&page->lru);
 		spin_unlock(&pool->lock);
@@ -836,20 +839,20 @@ static int z3fold_reclaim_page(struct z3
 		}
 		list_for_each_prev(pos, &pool->lru) {
 			page = list_entry(pos, struct page, lru);
+			zhdr = page_address(page);
 			if (test_bit(PAGE_HEADLESS, &page->private))
 				/* candidate found */
 				break;
 
-			zhdr = page_address(page);
 			if (!z3fold_page_trylock(zhdr))
 				continue; /* can't evict at this point */
 			kref_get(&zhdr->refcount);
 			list_del_init(&zhdr->buddy);
 			zhdr->cpu = -1;
-			set_bit(UNDER_RECLAIM, &page->private);
 			break;
 		}
 
+		set_bit(UNDER_RECLAIM, &page->private);
 		list_del_init(&page->lru);
 		spin_unlock(&pool->lock);
 
@@ -898,6 +901,7 @@ next:
 		if (test_bit(PAGE_HEADLESS, &page->private)) {
 			if (ret == 0) {
 				free_z3fold_page(page);
+				atomic64_dec(&pool->pages_nr);
 				return 0;
 			}
 			spin_lock(&pool->lock);
_