Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp1360ybm; Wed, 27 May 2020 17:23:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw+8pUEV2WGdhGu8+fIysCIe0p9l2m8eajxlZ8H6FEpYY1l4DYHaUqGWf+Hbet9v+CRSkg7 X-Received: by 2002:a17:906:f189:: with SMTP id gs9mr731946ejb.203.1590625386046; Wed, 27 May 2020 17:23:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590625386; cv=none; d=google.com; s=arc-20160816; b=buMFNPxlKx8QL7bmK4pDAUNewRS2JePf3ZsuPd/7Gts2btESu+nRb3WWGoyP7VjG7k VnokvY3d3r07i78V3B89orx8jp6nz0KGMtKXuj6PgPLKx9WCv+IlhZHiqgvGMbZ2dwEw W6lICsEI3s8ooLeR2gc4BUmnEKPOdLHDjEbOLDifvyL/XfduTjYXcRSZC2AYn3teKJah B9VsgL9pcwy/WHMgzCCjdWQ5gP0Kl4917nEydT8UWdNps3OBYHiL/9eYTcsdcIPM26Ek Q9LS3PHmJ/v8zhLEX/Y/1+F29qRyFLJO+AasRjJyg5eYTY/z8P0YfISPN6QF7u98yZWi Sj4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-disposition:mime-version:message-id:subject:cc:to:from:date :dkim-signature; bh=3NfM/YRWw8tWtCVntluiCugDqJX5J7Mi6y5RyulO5Co=; b=UyZn21SvIt73DniNairk2Xqesvo8WeP45DD+Z2t1bAs2qYrhSdF7AIeapp+V8YIixw qF5A3rChS4ihrqXta6bXga8BQXKItTrnxiN9kYLo2Z00KNWDgStOonR06/bCbKpyMAmO K9eEs9XdTIZ4bjpaNML83+zOIu1nCB3AU2BUFb/f/hcsYYhU5+GfOLyCqlI7SFHbm9qt tng3ZiVT5UmVEpcXjsdvJrvKyH3A5fSq2XXQrfMWzDQ763tGjN4QVGSYcDXdiZz/X7AG qmHOvxBIZC1tIlIrG2Lk8IqK9Ud0BykmYcRd6b5XdlA1lhrHvgCkgKPWeWoYAdugkrem VRpg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=h1jtgxnA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id eb11si3419915edb.302.2020.05.27.17.22.41; Wed, 27 May 2020 17:23:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=h1jtgxnA; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725825AbgE1AUx (ORCPT + 99 others); Wed, 27 May 2020 20:20:53 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:20413 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725793AbgE1AUx (ORCPT ); Wed, 27 May 2020 20:20:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1590625251; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=3NfM/YRWw8tWtCVntluiCugDqJX5J7Mi6y5RyulO5Co=; b=h1jtgxnAzQph09mJabMY9jcpazYEL6ChAclXRyCVqvk48TUdURDvVLybKR2meXwzlrcDd9 MognWJ/M1FsGJrY4zUKWE4ffh7RjKWYAOjBNXcAf7zvgMgokqj9pOjguI3N62SODbJSRF0 08MFNT7zwUxvvkyf2sbdXlUcg7yXw4k= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-262--4PlExgtPwKJVseeIiuy9A-1; Wed, 27 May 2020 20:20:44 -0400 X-MC-Unique: -4PlExgtPwKJVseeIiuy9A-1 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id D96EC460; Thu, 28 May 2020 00:20:40 +0000 (UTC) Received: from redhat.com (ovpn-119-19.rdu2.redhat.com [10.10.119.19]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2FCE85D9CC; Thu, 28 May 2020 00:20:35 +0000 (UTC) Date: Wed, 27 May 2020 20:20:33 -0400 From: Jerome Glisse To: linux-mm@kvack.org, Andrew Morton , Huang Ying Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Steven Capper , Catalin Marinas , Rabin Vincent , linux-arm-kernel@lists.infradead.org, rmk+kernel@arm.linux.org.uk, Guo Ren , linux-mips@vger.kernel.org, Ralf Baechle , Paul Burton , James Hogan , Ley Foon Tan , nios2-dev@lists.rocketboards.org, linux-parisc@vger.kernel.org, Helge Deller , "James E.J. Bottomley" , Yoshinori Sato , Rich Felker , linux-sh@vger.kernel.org, "David S. Miller" , sparclinux@vger.kernel.org, Guan Xuetao , linux-xtensa@linux-xtensa.org, Max Filippov , Chris Zankel Subject: Cache flush issue with page_mapping_file() and swap back shmem page ? Message-ID: <20200528002033.GB1992500@redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --/04w6evG8XlLl3ft Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit So any arch code which uses page_mapping_file() might get the wrong answer, this function will return NULL for a swap backed page which can be a shmem pages. But shmem pages can still be shared among multiple process (and possibly at different virtual addresses if mremap was use). Attached is a patch that changes page_mapping_file() to return the shmem mapping for swap backed shmem page. I have not tested it (no way for me to test all those architecture) and i spotted this while working on something else. So i hope someone can take a closer look. Cheers, J?r?me --/04w6evG8XlLl3ft Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="0001-mm-fix-cache-flush-for-shmem-page-that-are-swap-back.patch" Content-Transfer-Encoding: 8bit From 6c76b9f8baa87ff872f6be5a44805a74c1e07fea Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= Date: Wed, 27 May 2020 20:18:59 -0400 Subject: [PATCH] mm: fix cache flush for shmem page that are swap backed. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This might be a shmem page that is in a sense a file that can be mapped multiple times in different processes at possibly different virtual addresses (fork + mremap). So return the shmem mapping that will allow any arch code to find all mappings of the page. Note that even if page is not anonymous then the page might have a NULL page->mapping field if it is being truncated, but then it is fine as each pte poiting to the page will be remove and cache flushing should be handled properly by that part of the code. Signed-off-by: J?r?me Glisse Cc: "Huang, Ying" Cc: Michal Hocko Cc: Mel Gorman Cc: Russell King Cc: Andrew Morton Cc: Mike Rapoport Cc: "David S. Miller" Cc: "James E.J. Bottomley" --- mm/util.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/mm/util.c b/mm/util.c index 988d11e6c17c..ec8739ab0cc3 100644 --- a/mm/util.c +++ b/mm/util.c @@ -685,8 +685,24 @@ EXPORT_SYMBOL(page_mapping); */ struct address_space *page_mapping_file(struct page *page) { - if (unlikely(PageSwapCache(page))) + if (unlikely(PageSwapCache(page))) { + /* + * This might be a shmem page that is in a sense a file that + * can be mapped multiple times in different processes at + * possibly different virtual addresses (fork + mremap). So + * return the shmem mapping that will allow any arch code to + * find all mappings of the page. + * + * Note that even if page is not anonymous then the page might + * have a NULL page->mapping field if it is being truncated, + * but then it is fine as each pte poiting to the page will be + * remove and cache flushing should be handled properly by that + * part of the code. + */ + if (!PageAnon(page)) + return page->mapping; return NULL; + } return page_mapping(page); } -- 2.26.2 --/04w6evG8XlLl3ft--