Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2477552imm; Mon, 28 May 2018 08:50:37 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrM/vFXJBYwzLlGvkCJYFK4uV8dWZnjm4kEEnQyTJFhhdvt2XbN94QpHnjp7YTBIY+vNDCS X-Received: by 2002:a62:e408:: with SMTP id r8-v6mr14023052pfh.172.1527522636999; Mon, 28 May 2018 08:50:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527522636; cv=none; d=google.com; s=arc-20160816; b=etJHp2AjGPCmG60EmcpwsTmxndMbXHeKR06dcSdpfz4HsGQTNS/6cVueek3DwhFahR DJ0RoRrcormMRVnetlKFebF543e46JVpiaQ+HQe6ttDna1HnhdOWNtWlPmeJ8aS6A291 E3xevNhDogmd2YvFUUaHhZOriWuWkvojdZB0Zdj1YzCg0Cjd2au1uzxMiRXk3YaKK4iE u2IjUUATABikybsI3KSvW+xLDP938XTZ/kF4P5cOTtb4VI0QjMGDh6AsfruxJNEZitZq 003aEQTmORQZ9dT4LWZSG1BdTzcoH6FKLunKLLz80qE0mSyvl67sQL2PoRh9R3Uhy0S5 moVw== 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=tuxQPgr8eP2nPL2r9Tw0Z/QuwGKwH51U6nL4bHI/E44=; b=IZwmBZADpIuknNEHad0eplf67sScJeBxnplGNxq0w6b+u2fnbpwoGziQ0CjAaosG/j eUip6j3lZ4DGEbG/gI+BeQxE8+bsYlvr3zQ9ygt1/jKcEsKpzx8wETC/wyfY3klVIDE1 ikEwoOtPFv1thLS+uEgkZ0hFJIKUZTFv/xwJv7UlQOr5jCm368xRqDV2oHVRv6TefmCv /+ZakRqKvshz6VvAzhZjOfAKP/IBHFs13hEZKxY1gF38YpnS6Lw5I9lMs4tFYDdje67W Coas/lTFUJTNbcEOSqyLowm97CONtnLyCXdPtJuTaNlz+JSzePVgfHg9DFQLmfjF4Tb8 3oQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=FPA3/QT6; 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 f91-v6si30796664plb.510.2018.05.28.08.50.22; Mon, 28 May 2018 08:50:36 -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=FPA3/QT6; 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 S1034952AbeE1Ptv (ORCPT + 99 others); Mon, 28 May 2018 11:49:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:36420 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936947AbeE1KQP (ORCPT ); Mon, 28 May 2018 06:16:15 -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 58C94208AD; Mon, 28 May 2018 10:16:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1527502574; bh=93l+hQj00Yh2VeNtSCYgX1vP/oE76jCikDL63/Tkmrk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FPA3/QT60313e+CpD8CFC777CnBOC5ftu+s28oDOZr0Ok0kQEezkDstVGXLIuMdD3 7O9F2ccT/EXYf8MrICKZ7V3obd3B2INwGAxnzSIGBk69smvI+uPul+TwuVyR2TVv3s tcRJyQpUj9QDPfw126H2J+8clrKbOxzqZep1Dhz4= 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 4.4 052/268] mm: pin address_space before dereferencing it while isolating an LRU page Date: Mon, 28 May 2018 12:00:26 +0200 Message-Id: <20180528100207.850665533@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180528100202.045206534@linuxfoundation.org> References: <20180528100202.045206534@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 4.4-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 @@ -1312,6 +1312,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) @@ -1320,10 +1321,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; } }