From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3B5AC43333 for ; Sun, 22 Mar 2020 01:22:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9463F20722 for ; Sun, 22 Mar 2020 01:22:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="sIgkxHmI" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9463F20722 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 44C026B000C; Sat, 21 Mar 2020 21:22:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FC0D6B000D; Sat, 21 Mar 2020 21:22:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 339DD6B000E; Sat, 21 Mar 2020 21:22:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id 1A58A6B000C for ; Sat, 21 Mar 2020 21:22:30 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D60F052C0 for ; Sun, 22 Mar 2020 01:22:29 +0000 (UTC) X-FDA: 76621248018.15.root67_15c5c3de5bd60 X-HE-Tag: root67_15c5c3de5bd60 X-Filterd-Recvd-Size: 4135 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Sun, 22 Mar 2020 01:22:29 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (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 0AB9E20757; Sun, 22 Mar 2020 01:22:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1584840148; bh=GPIJXAU8IdYJRQY6I34QACgs/PHeLhjUhfPVGA19puk=; h=Date:From:To:Subject:In-Reply-To:From; b=sIgkxHmIyg5bf/bNSgO7qViDIKy9HuWF7IIlhuaPb1m8jG+rAtrzuBSJnD578Y6fJ Ejne412lZYBQF153iO3yl0FGXeUvusqkVOvSu1gkAdvPcKGsviMNEXKv0Xu8wPufd+ Fq6/xCgKkS6NxaT8yDMn+s4cOL/b+ksa+qgfpnQU= Date: Sat, 21 Mar 2020 18:22:26 -0700 From: Andrew Morton To: akpm@linux-foundation.org, dancol@google.com, dave.hansen@intel.com, jannh@google.com, joel@joelfernandes.org, linux-mm@kvack.org, mhocko@suse.com, minchan@kernel.org, mm-commits@vger.kernel.org, stable@vger.kernel.org, torvalds@linux-foundation.org, vbabka@suse.cz Subject: [patch 06/10] mm: do not allow MADV_PAGEOUT for CoW pages Message-ID: <20200322012226.yY5JKgG__%akpm@linux-foundation.org> In-Reply-To: <20200321181954.c0564dfd5514cd742b534884@linux-foundation.org> User-Agent: s-nail v14.8.16 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: From: Michal Hocko Subject: mm: do not allow MADV_PAGEOUT for CoW pages Jann has brought up a very interesting point [1]. While shared pages are excluded from MADV_PAGEOUT normally, CoW pages can be easily reclaimed that way. This can lead to all sorts of hard to debug problems. E.g. performance problems outlined by Daniel [2]. There are runtime environments where there is a substantial memory shared among security domains via CoW memory and a easy to reclaim way of that memory, which MADV_{COLD,PAGEOUT} offers, can lead to either performance degradation in for the parent process which might be more privileged or even open side channel attacks. The feasibility of the latter is not really clear to me TBH but there is no real reason for exposure at this stage. It seems there is no real use case to depend on reclaiming CoW memory via madvise at this stage so it is much easier to simply disallow it and this is what this patch does. Put it simply MADV_{PAGEOUT,COLD} can operate only on the exclusively owned memory which is a straightforward semantic. [1] http://lkml.kernel.org/r/CAG48ez0G3JkMq61gUmyQAaCq=_TwHbi1XKzWRooxZkv08PQKuw@mail.gmail.com [2] http://lkml.kernel.org/r/CAKOZueua_v8jHCpmEtTB6f3i9e2YnmX4mqdYVWhV4E=Z-n+zRQ@mail.gmail.com Link: http://lkml.kernel.org/r/20200312082248.GS23944@dhcp22.suse.cz Fixes: 9c276cc65a58 ("mm: introduce MADV_COLD") Signed-off-by: Michal Hocko Reported-by: Jann Horn Acked-by: Vlastimil Babka Cc: Minchan Kim Cc: Daniel Colascione Cc: Dave Hansen Cc: "Joel Fernandes (Google)" Cc: Signed-off-by: Andrew Morton --- mm/madvise.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) --- a/mm/madvise.c~mm-do-not-allow-madv_pageout-for-cow-pages +++ a/mm/madvise.c @@ -335,12 +335,14 @@ static int madvise_cold_or_pageout_pte_r } page = pmd_page(orig_pmd); + + /* Do not interfere with other mappings of this page */ + if (page_mapcount(page) != 1) + goto huge_unlock; + if (next - addr != HPAGE_PMD_SIZE) { int err; - if (page_mapcount(page) != 1) - goto huge_unlock; - get_page(page); spin_unlock(ptl); lock_page(page); @@ -426,6 +428,10 @@ regular_page: continue; } + /* Do not interfere with other mappings of this page */ + if (page_mapcount(page) != 1) + continue; + VM_BUG_ON_PAGE(PageTransCompound(page), page); if (pte_young(ptent)) { _