Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2527856imm; Mon, 28 May 2018 09:47:39 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqKc1Gf1Ztj6DqNB+cxaOYZGocigSnYicoS9jPVJF2oGFIpK7QeYGzoGfFfQDF+j23H++ve X-Received: by 2002:a65:460f:: with SMTP id v15-v6mr11131279pgq.31.1527526059316; Mon, 28 May 2018 09:47:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527526059; cv=none; d=google.com; s=arc-20160816; b=D3Pow77aR446HHE2ISl5qZXajyldrI+EKCw+DUks9ifyK6YlFJwTenFuHEP0fEwnXd 5Vr0ntm934OQ9RJwp8toalddjMnLQK2Si+NAhDZvlpZSFhVHcqyK4RnpXRL6t1QMHJEt tHZ1i25HaeESvFWWzhGazeysmsJdx8lIV9A3ir2luEgh15p2YZJWNZqXEgDSaAEl2OPA vXxoM1FDo32skevKnqVy9EuwX0Ecsy3cF4LeegsZpkqePIRs+ePGvchsQBCbFXVBao9w leH05rL2lZ+NSaCaOyEec/dYOEbce1WNXagBiyqPS7aCqW5+ZQQF9BzG8TbW2rxM9u++ thng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=uXXjvGt2dY6UeCX8zApau+cWgAsa9MfndyrKIEqguRw=; b=1IR1NjUr3N9dnm1aR3whKtnp8bB2gmooRPkitwaAw9CeR8lHfck+OD3OknEvKvn+wq zG0NAQtEIzvBUIx1wpPXYwFEG8Dxx0Jh9Mtvu92tjn1CvVRSq+RcLb3LqwhhQI36xx9Q EnOq2qfyqxSbYx3th2A823h085VQ18QE3Blf//SLKi7fEHQt3KyXTjefFqj0uoAoB7Se YeHNRuYX0dGIGb3QKBBGH3Ydx7fQN3kpMVf+a/o5wsk8nV61S0ZHSPFf2V8UGljb4H4d ojkDdqqNAf4PXLW8IyCgz+OX6CB+tcM0WnwYX+rlIajxuSQehbUZlbq2jA9uyWEsD6/3 G62Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qI8TnbiG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v64-v6si3442846pfj.292.2018.05.28.09.47.24; Mon, 28 May 2018 09:47:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qI8TnbiG; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S940236AbeE1QqH (ORCPT + 99 others); Mon, 28 May 2018 12:46:07 -0400 Received: from mail.kernel.org ([198.145.29.99]:55122 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932224AbeE1KHF (ORCPT ); Mon, 28 May 2018 06:07:05 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1D7F6208A6; Mon, 28 May 2018 10:07:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1527502024; bh=m55DE7lH5fY1Fg+jdFdx1jPv8gtXz/9ZhfTjrSZAKow=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qI8TnbiGvD6kS32B88COcxa7JKFbBXhwgwePQYJFKqNTpsEvgLGf9arif9hcUascM 27iO3rPnGlmAjHJYVYIYq4p9kiZBAQZDUsRhMOTxTGfMlcbLDDfu3736OiNYQDgGE+ LGN8gpXETaPqwDj0o01ghILQGMbN5ZVR0ICCUEDs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mel Gorman , Minchan Kim , "Huang, Ying" , Jan Kara , Andrew Morton , Linus Torvalds , Sasha Levin Subject: [PATCH 3.18 032/185] mm: pin address_space before dereferencing it while isolating an LRU page Date: Mon, 28 May 2018 12:01:13 +0200 Message-Id: <20180528100052.556669568@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180528100050.700971285@linuxfoundation.org> References: <20180528100050.700971285@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Mel Gorman [ Upstream commit 69d763fc6d3aee787a3e8c8c35092b4f4960fa5d ] Minchan Kim asked the following question -- what locks protects address_space destroying when race happens between inode trauncation and __isolate_lru_page? Jan Kara clarified by describing the race as follows CPU1 CPU2 truncate(inode) __isolate_lru_page() ... truncate_inode_page(mapping, page); delete_from_page_cache(page) spin_lock_irqsave(&mapping->tree_lock, flags); __delete_from_page_cache(page, NULL) page_cache_tree_delete(..) ... mapping = page_mapping(page); page->mapping = NULL; ... spin_unlock_irqrestore(&mapping->tree_lock, flags); page_cache_free_page(mapping, page) put_page(page) if (put_page_testzero(page)) -> false - inode now has no pages and can be freed including embedded address_space if (mapping && !mapping->a_ops->migratepage) - we've dereferenced mapping which is potentially already free. The race is theoretically possible but unlikely. Before the delete_from_page_cache, truncate_cleanup_page is called so the page is likely to be !PageDirty or PageWriteback which gets skipped by the only caller that checks the mappping in __isolate_lru_page. Even if the race occurs, a substantial amount of work has to happen during a tiny window with no preemption but it could potentially be done using a virtual machine to artifically slow one CPU or halt it during the critical window. This patch should eliminate the race with truncation by try-locking the page before derefencing mapping and aborting if the lock was not acquired. There was a suggestion from Huang Ying to use RCU as a side-effect to prevent mapping being freed. However, I do not like the solution as it's an unconventional means of preserving a mapping and it's not a context where rcu_read_lock is obviously protecting rcu data. Link: http://lkml.kernel.org/r/20180104102512.2qos3h5vqzeisrek@techsingularity.net Fixes: c82449352854 ("mm: compaction: make isolate_lru_page() filter-aware again") Signed-off-by: Mel Gorman Acked-by: Minchan Kim Cc: "Huang, Ying" Cc: Jan Kara Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- mm/vmscan.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1215,6 +1215,7 @@ int __isolate_lru_page(struct page *page if (PageDirty(page)) { struct address_space *mapping; + bool migrate_dirty; /* ISOLATE_CLEAN means only clean pages */ if (mode & ISOLATE_CLEAN) @@ -1223,10 +1224,19 @@ int __isolate_lru_page(struct page *page /* * Only pages without mappings or that have a * ->migratepage callback are possible to migrate - * without blocking + * without blocking. However, we can be racing with + * truncation so it's necessary to lock the page + * to stabilise the mapping as truncation holds + * the page lock until after the page is removed + * from the page cache. */ + if (!trylock_page(page)) + return ret; + mapping = page_mapping(page); - if (mapping && !mapping->a_ops->migratepage) + migrate_dirty = mapping && mapping->a_ops->migratepage; + unlock_page(page); + if (!migrate_dirty) return ret; } }