From patchwork Mon Jan 28 12:16:09 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 10783641 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id BF90E13B5 for ; Mon, 28 Jan 2019 12:16:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A9CFE2A736 for ; Mon, 28 Jan 2019 12:16:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9A0E32A752; Mon, 28 Jan 2019 12:16:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 047202A736 for ; Mon, 28 Jan 2019 12:16:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5ACE88E0007; Mon, 28 Jan 2019 07:16:25 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 55C0A8E0001; Mon, 28 Jan 2019 07:16:25 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 471E58E0007; Mon, 28 Jan 2019 07:16:25 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by kanga.kvack.org (Postfix) with ESMTP id 19E128E0001 for ; Mon, 28 Jan 2019 07:16:25 -0500 (EST) Received: by mail-qk1-f198.google.com with SMTP id k66so18116297qkf.1 for ; Mon, 28 Jan 2019 04:16:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id; bh=TK96U1go4zqbtsuVGbVmpPmjd+GVv1COkR+NvBptkt8=; b=AfIAEfyRyxs9vl7d06d8dJamiAzZ4Gjq0a0oGCFSBuirkpf6A4oUj3ee1Eo1hWtASV UOeWG3xaY70dJjQSm6T5u6xb7+E5mm8vVeNYXf/veVgoUSdD7nj2T8PKrFHuRmMmRtqx anqjPM3mSl2UgvNMAN92AZMXUdWdRlOV22KqsWRua35oGWlaV0pA3e1y61TubtYwmUmc wKqG8iWHmSmCxOjmFsFdADB/jmtoX0a8D0j+tRAiMgzxIw+5ojqFL6d0DzS6ZQXxZlsJ oDT1+fLT1Tc3QUVcKhEX0CPpH6Ua+VH84EffjyWUFvWP4xjauPxAjOL2n2KMCivdPs51 fhBA== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of david@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Gm-Message-State: AJcUukfcTqp2Xl5thkkH8w73Lf0GUh9OBX1xUk0oTd3zsXyyoDWDETQk lUHuuVG6peWZ2YyamHwLNB01Cp09QEI3hKWUv88Y/+palshuCUO5wb/5q14vFA7JApxXEHRjiIQ zKhBmBP4acm8w6zp9mfQHsnQWTqG4eA/0+xB/xYd8wuN148yWE0qR44oe8FOomtNZ1Q== X-Received: by 2002:a37:8fc1:: with SMTP id r184mr19155227qkd.32.1548677784814; Mon, 28 Jan 2019 04:16:24 -0800 (PST) X-Google-Smtp-Source: ALg8bN4ct+ecPBxGlEctnd2jpqyW71R2hHSqt6s73TUQhXSUBC6kNbcLPRgJA4zZynDDQu2eW8fw X-Received: by 2002:a37:8fc1:: with SMTP id r184mr19155194qkd.32.1548677784099; Mon, 28 Jan 2019 04:16:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548677784; cv=none; d=google.com; s=arc-20160816; b=NsTJmI4SSQaFRyGfvsAEADjwnooqBZuweEPaMnnRu0OdkAa7g0pAKtJEXaR64wckUm WnXnZfzM319rWx3YEzM9qVFyWh46NoS1YzJedR7GdBYAtvpHEjP6MksSfMPf4OoPJX0a ARAg7lg3JvllxJyQgoUhKeml2j95iL7xwPD/Y67s2lNAyRgpqmFWMkPMXECWrtsGNtaX u0nOBhKCi1ZqqaSEKxM4L2CFky0RtHZZyC+DWg4SYUZFwvhNQmeOG52MQsV11cqvb7BI WEdXxAVONK9MYZB2zkTGdn69I0mYWMM18FQFKV++jwJGRWdXwfuUo3PRptB4HXc8A5cV S7cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from; bh=TK96U1go4zqbtsuVGbVmpPmjd+GVv1COkR+NvBptkt8=; b=rJHYs4O9Oo9kImujI5vcINSXSwzc0Z8cEnbRRjXAKYt+A657qBqVXDDAhSvcFJgVs3 xj1FWp+Exzs1ToLVugpA1IV9nUwjL9z0F1Z2ycB5/BEt+e0gbkcJNUSYs5+VpvNJwQQX 5ujEsnl+4e1S43jyl2c/o/D8FLkHm3cxWnvgJCezASSWwjjSYGhrLMHqvTazQzdKM6bN GhTYo29etYbirbDhP/2YorvvzsHkOLyb35tODxIpD1uSxebYu9ZM92Gljgo5fNO0o5zQ uRjfhKrIZe6pP3DbtfsaGcXIZE4YBZCvWW+XbJUj6rJnIr0NILgWYsNhZCnnFb9C6vr0 kSMQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of david@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id f64si1446125qva.93.2019.01.28.04.16.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Jan 2019 04:16:24 -0800 (PST) Received-SPF: pass (google.com: domain of david@redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; Authentication-Results: mx.google.com; spf=pass (google.com: domain of david@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9AC81C002965; Mon, 28 Jan 2019 12:16:22 +0000 (UTC) Received: from t460s.redhat.com (ovpn-117-107.ams2.redhat.com [10.36.117.107]) by smtp.corp.redhat.com (Postfix) with ESMTP id E60895D969; Mon, 28 Jan 2019 12:16:10 +0000 (UTC) From: David Hildenbrand To: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, David Hildenbrand , Andrew Morton , Mel Gorman , "Kirill A. Shutemov" , Michal Hocko , Naoya Horiguchi , Jan Kara , Andrea Arcangeli , Dominik Brodowski , Matthew Wilcox , Vratislav Bendel , Rafael Aquini Subject: [PATCH RFC] mm: migrate: don't rely on PageMovable() of newpage after unlocking it Date: Mon, 28 Jan 2019 13:16:09 +0100 Message-Id: <20190128121609.9528-1-david@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 28 Jan 2019 12:16:23 +0000 (UTC) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP While debugging some crashes related to virtio-balloon deflation that happened under the old balloon migration code, I stumbled over a possible race I think. What we experienced: drivers/virtio/virtio_balloon.c:release_pages_balloon(): - WARNING: CPU: 13 PID: 6586 at lib/list_debug.c:59 __list_del_entry+0xa1/0xd0 - list_del corruption. prev->next should be ffffe253961090a0, but was dead000000000100 Turns out after having added the page to a local list when dequeuing, the page would suddenly be moved to an LRU list before we would free it via the local list, corrupting both lists. So a page we own and that is !LRU was moved to an LRU list. For us, this was triggered by backporting 195a8c43e93d8 ("virtio-balloon: deflate via a page list") onto old balloon compaction code, but I think this only made the BUG become visible and the race still exists in new !LRU migraton code. My theory: In __unmap_and_move(), we lock the old and newpage and perform the migration. In case of vitio-balloon, the new page will become movable, the old page will no longer be movable. However, after unlocking newpage, I think there is nothing stopping the newpage from getting dequeued and freed by virtio-balloon. This will result in the newpage 1. No longer having PageMovable() 2. Getting moved to the local list before finally freeing it (using page->lru) Back in the migration thread in __unmap_and_move(), we would after unlocking the newpage suddenly no longer have PageMovable(newpage) and will therefore call putback_lru_page(newpage), modifying page->lru although that list is still in use by virtio-balloon. To summarize, we have a race between migrating the newpage and checking for PageMovable(newpage). Instead of checking __PageMovable(newpage), we can simply rely on is_lru. Because if the old page was not an LRU page, the new page also shouldn't be. If there is a problem with that, we could check for __PageMovable(newpage) before unlocking the new page. As I am not yet sure if this race actually exists, especially also upstream, I am sending this as RFC. Cc: Andrew Morton Cc: Mel Gorman Cc: "Kirill A. Shutemov" Cc: Michal Hocko Cc: Naoya Horiguchi Cc: Jan Kara Cc: Andrea Arcangeli Cc: Dominik Brodowski Cc: Matthew Wilcox Cc: Vratislav Bendel Cc: Rafael Aquini Reported-by: Vratislav Bendel Signed-off-by: David Hildenbrand Acked-by: Michal Hocko Acked-by: Rafael Aquini --- mm/migrate.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/mm/migrate.c b/mm/migrate.c index 4512afab46ac..31e002270b05 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1135,10 +1135,12 @@ static int __unmap_and_move(struct page *page, struct page *newpage, * If migration is successful, decrease refcount of the newpage * which will not free the page because new page owner increased * refcounter. As well, if it is LRU page, add the page to LRU - * list in here. + * list in here. Don't rely on PageMovable(newpage), as that could + * already have changed after unlocking newpage (e.g. + * virtio-balloon deflation). */ if (rc == MIGRATEPAGE_SUCCESS) { - if (unlikely(__PageMovable(newpage))) + if (unlikely(!is_lru)) put_page(newpage); else putback_lru_page(newpage);