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=-16.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham 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 772CCC433DB for ; Tue, 23 Mar 2021 00:49:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1E9E16196C for ; Tue, 23 Mar 2021 00:49:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E9E16196C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3AF3D6B012C; Mon, 22 Mar 2021 20:49:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 30D376B012E; Mon, 22 Mar 2021 20:49:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F1C316B012F; Mon, 22 Mar 2021 20:49:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0101.hostedemail.com [216.40.44.101]) by kanga.kvack.org (Postfix) with ESMTP id C4A096B012C for ; Mon, 22 Mar 2021 20:49:38 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8946762F2 for ; Tue, 23 Mar 2021 00:49:38 +0000 (UTC) X-FDA: 77949306036.01.B7E3ADA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf05.hostedemail.com (Postfix) with ESMTP id B379AE0001AC for ; Tue, 23 Mar 2021 00:49:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616460577; 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: in-reply-to:in-reply-to:references:references; bh=bmYAjaH54F633I35l9apxE4WoJ10q7xNHsvAC/VJ+ZA=; b=Afn42jchpcK1LVnG3Wp0gdbAek0DUKYkzav7BdCwPMu3mG5i5mKwAmr+XQ8DxYr7GYaS/h Di8LFbO17JD+N7GO0im9W5nAd6SH3iUobta3aysTSVn2dNHXOWTZScqf2jeDTYLK9JQ84r lJ2w5nTRWjMzT5WzF6KuhEm06Av+jLU= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-187-X7BlhdJEPwCJVgpUhh2HUw-1; Mon, 22 Mar 2021 20:49:35 -0400 X-MC-Unique: X7BlhdJEPwCJVgpUhh2HUw-1 Received: by mail-qk1-f198.google.com with SMTP id b78so806179qkg.13 for ; Mon, 22 Mar 2021 17:49:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=bmYAjaH54F633I35l9apxE4WoJ10q7xNHsvAC/VJ+ZA=; b=OTzwiByCqo/NBPFWIHqKfkZoXdm47B0Ivy7bbqI2fJJ6kbbTU056cZuV2Wc4cWcw3g 8UKOO9mDEPCciKUPUZ0EAI0yrbvmbR3qCBFsWyBYYnIb8f1Tgr6Do2TGXAkFIZkgHFGk y0J600Vwu6VvE1UiQ/Ss1CQEZjq1g3rMqcm4JB5edpu12Zh22Vx11QcOQJMxM3KDJawv nVH9nvCz62/Yo2UQrJnNkXJX6yPbMTyqW7YMWK/AC3DMy/J8Dv6iJbJZDYMDtc9qmR9k RSmJy8Q7oGGAjgfFBO6pjshHKPoWoEAThdcY8qgGmX6J0IIyxWe2lHXkwp+Mrw28R4My 8How== X-Gm-Message-State: AOAM53233W6w+o2G8vqG4Mqv7yWsGOhkpwfM1nO2c2gDnyiG5OXk+T2K onnwiC1nZKsZzc/kUto6waTaM7js8dRrM0TIi5tQYMhb9kZ5fhxxq95zjg4SB/6/iIrzAISfKzl OVU3WrfWKC/k= X-Received: by 2002:a05:620a:819:: with SMTP id s25mr3093169qks.485.1616460575298; Mon, 22 Mar 2021 17:49:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwndVaIK/rU/VfjU2g3FSUD8i9gf3stvyGR9MZB2GR8CImkA5nMNn5+tsv84lL9aYUj/HBNgQ== X-Received: by 2002:a05:620a:819:: with SMTP id s25mr3093145qks.485.1616460575052; Mon, 22 Mar 2021 17:49:35 -0700 (PDT) Received: from localhost.localdomain (bras-base-toroon474qw-grc-82-174-91-135-175.dsl.bell.ca. [174.91.135.175]) by smtp.gmail.com with ESMTPSA id n6sm5031793qtx.22.2021.03.22.17.49.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Mar 2021 17:49:33 -0700 (PDT) From: Peter Xu To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: "Kirill A . Shutemov" , Jerome Glisse , Mike Kravetz , Matthew Wilcox , Andrew Morton , Axel Rasmussen , Hugh Dickins , peterx@redhat.com, Nadav Amit , Andrea Arcangeli , Mike Rapoport Subject: [PATCH 12/23] shmem/userfaultfd: Allows file-back mem to be uffd wr-protected on thps Date: Mon, 22 Mar 2021 20:49:01 -0400 Message-Id: <20210323004912.35132-13-peterx@redhat.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20210323004912.35132-1-peterx@redhat.com> References: <20210323004912.35132-1-peterx@redhat.com> MIME-Version: 1.0 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="US-ASCII" X-Stat-Signature: c6touizkmtfuexfseeqqkrycp6w3z9ua X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: B379AE0001AC Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf05; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616460577-849542 Content-Transfer-Encoding: quoted-printable 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: We don't have "huge" version of PTE_SWP_UFFD_WP_SPECIAL, instead when nec= essary we split the thp if the huge page is uffd wr-protected previously. However split the thp is not enough, because file-backed thp is handled t= otally differently comparing to anonymous thps - rather than doing a real split,= the thp pmd will simply got dropped in __split_huge_pmd_locked(). That is definitely not enough if e.g. when there is a thp covers range [0= , 2M) but we want to wr-protect small page resides in [4K, 8K) range, because a= fter __split_huge_pmd() returns, there will be a none pmd. Here we leverage the previously introduced change_protection_prepare() ma= cro so that we'll populate the pmd with a pgtable page. Then change_pte_range()= will do all the rest for us, e.g., install the uffd-wp swap special pte marker= at any pte that we'd like to wr-protect, under the protection of pgtable loc= k. Signed-off-by: Peter Xu --- mm/mprotect.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/mm/mprotect.c b/mm/mprotect.c index 6b63e3544b47..51c954afa406 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -296,8 +296,16 @@ static inline unsigned long change_pmd_range(struct = vm_area_struct *vma, } =20 if (is_swap_pmd(*pmd) || pmd_trans_huge(*pmd) || pmd_devmap(*pmd)) { - if (next - addr !=3D HPAGE_PMD_SIZE) { + if (next - addr !=3D HPAGE_PMD_SIZE || + /* Uffd wr-protecting a file-backed memory range */ + unlikely(!vma_is_anonymous(vma) && + (cp_flags & MM_CP_UFFD_WP))) { __split_huge_pmd(vma, pmd, addr, false, NULL); + /* + * For file-backed, the pmd could have been + * gone; still provide a pte pgtable if needed. + */ + change_protection_prepare(vma, pmd, addr, cp_flags); } else { int nr_ptes =3D change_huge_pmd(vma, pmd, addr, newprot, cp_flags); --=20 2.26.2