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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8AB91D15D96 for ; Mon, 21 Oct 2024 14:13:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7A1C6B007B; Mon, 21 Oct 2024 10:13:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A29776B0082; Mon, 21 Oct 2024 10:13:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87BEC6B0083; Mon, 21 Oct 2024 10:13:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 6A9756B007B for ; Mon, 21 Oct 2024 10:13:39 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C72A3ACD38 for ; Mon, 21 Oct 2024 14:13:08 +0000 (UTC) X-FDA: 82697802138.22.223FCCC Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf13.hostedemail.com (Postfix) with ESMTP id 611C62000B for ; Mon, 21 Oct 2024 14:13:21 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="qXFYG/M1"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=292U25mV; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="qXFYG/M1"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=292U25mV; spf=pass (imf13.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729519817; h=from:from:sender: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:dkim-signature; bh=fyhbF/edolYkSSJeB9ofnUaVvEXdp0SuMQyMEkHiIVs=; b=avY/4Aqzau6RCC2ZHSiMR5rNExAr7CwqpYavMpCx3S2ClHHJnMOPwWaqyfO48b/fTqb1fE s1OZMy9JXMYGa8biH4stVwpOICB+WNHzlem5UJJA7zKuPNa8aHShWnxUL/Qn9UNall3riB bMK+DpEgLqyerAhso2LVjxg06e5qBW4= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="qXFYG/M1"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=292U25mV; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="qXFYG/M1"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=292U25mV; spf=pass (imf13.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729519817; a=rsa-sha256; cv=none; b=VOoPd1129+86V6CV2bo29RVx5UzAwYFolzo9j7enGKixibQi/HMGxHJedKtxHsRqbbFvO+ Uupxh7ZVtjy8Clh6IupbiNVbDhKUf+sS2jT4QWrNcygJio42qe5oJI4//7YLt5bpn9QZZa 603JbCSh9kCw/Akv1+38hrg4RrAlK4w= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 26A7521E7C; Mon, 21 Oct 2024 14:13:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1729520015; h=from:from:reply-to: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:autocrypt:autocrypt; bh=fyhbF/edolYkSSJeB9ofnUaVvEXdp0SuMQyMEkHiIVs=; b=qXFYG/M1qE1BVtBLwWkeblrQiBVDTDUZevQAJvwOXeVkm52aPUAsVY5ixIESQjIj+a0yTA CcYkoVxKoZhsoe70jnhB8Zv/ZGm+4TapaCBy/aIhaGr3srJdudKpdTvTaKunjxmWFLDnng YbE4grGgwSfuAPf/jmB4cBwBnlV+Nm4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1729520015; h=from:from:reply-to: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:autocrypt:autocrypt; bh=fyhbF/edolYkSSJeB9ofnUaVvEXdp0SuMQyMEkHiIVs=; b=292U25mVoWOZYFQelSghDKj01ojNgCy7hp7TwaRMyAMMUM7rIIWpA9aVHZDGZdYajamZ4N Aa0qgMD19s1YxiAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1729520015; h=from:from:reply-to: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:autocrypt:autocrypt; bh=fyhbF/edolYkSSJeB9ofnUaVvEXdp0SuMQyMEkHiIVs=; b=qXFYG/M1qE1BVtBLwWkeblrQiBVDTDUZevQAJvwOXeVkm52aPUAsVY5ixIESQjIj+a0yTA CcYkoVxKoZhsoe70jnhB8Zv/ZGm+4TapaCBy/aIhaGr3srJdudKpdTvTaKunjxmWFLDnng YbE4grGgwSfuAPf/jmB4cBwBnlV+Nm4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1729520015; h=from:from:reply-to: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:autocrypt:autocrypt; bh=fyhbF/edolYkSSJeB9ofnUaVvEXdp0SuMQyMEkHiIVs=; b=292U25mVoWOZYFQelSghDKj01ojNgCy7hp7TwaRMyAMMUM7rIIWpA9aVHZDGZdYajamZ4N Aa0qgMD19s1YxiAQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D7F87139E0; Mon, 21 Oct 2024 14:13:34 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id ErIbNI5hFmc4UQAAD6G6ig (envelope-from ); Mon, 21 Oct 2024 14:13:34 +0000 Message-ID: <470886d2-9f6f-4486-a935-daea4c5bea09@suse.cz> Date: Mon, 21 Oct 2024 16:13:34 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/5] mm: add PTE_MARKER_GUARD PTE marker Content-Language: en-US To: Lorenzo Stoakes , Andrew Morton Cc: Suren Baghdasaryan , "Liam R . Howlett" , Matthew Wilcox , "Paul E . McKenney" , Jann Horn , David Hildenbrand , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Muchun Song , Richard Henderson , Ivan Kokshaysky , Matt Turner , Thomas Bogendoerfer , "James E . J . Bottomley" , Helge Deller , Chris Zankel , Max Filippov , Arnd Bergmann , linux-alpha@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linux-arch@vger.kernel.org, Shuah Khan , Christian Brauner , linux-kselftest@vger.kernel.org, Sidhartha Kumar , Jeff Xu , Christoph Hellwig , linux-api@vger.kernel.org, John Hubbard References: <081837b697a98c7fa5832542b20f603d49e0b557.1729440856.git.lorenzo.stoakes@oracle.com> From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJkBREIBQkRadznAAoJECJPp+fMgqZkNxIQ ALZRqwdUGzqL2aeSavbum/VF/+td+nZfuH0xeWiO2w8mG0+nPd5j9ujYeHcUP1edE7uQrjOC Gs9sm8+W1xYnbClMJTsXiAV88D2btFUdU1mCXURAL9wWZ8Jsmz5ZH2V6AUszvNezsS/VIT87 AmTtj31TLDGwdxaZTSYLwAOOOtyqafOEq+gJB30RxTRE3h3G1zpO7OM9K6ysLdAlwAGYWgJJ V4JqGsQ/lyEtxxFpUCjb5Pztp7cQxhlkil0oBYHkudiG8j1U3DG8iC6rnB4yJaLphKx57NuQ PIY0Bccg+r9gIQ4XeSK2PQhdXdy3UWBr913ZQ9AI2usid3s5vabo4iBvpJNFLgUmxFnr73SJ KsRh/2OBsg1XXF/wRQGBO9vRuJUAbnaIVcmGOUogdBVS9Sun/Sy4GNA++KtFZK95U7J417/J Hub2xV6Ehc7UGW6fIvIQmzJ3zaTEfuriU1P8ayfddrAgZb25JnOW7L1zdYL8rXiezOyYZ8Fm ZyXjzWdO0RpxcUEp6GsJr11Bc4F3aae9OZtwtLL/jxc7y6pUugB00PodgnQ6CMcfR/HjXlae h2VS3zl9+tQWHu6s1R58t5BuMS2FNA58wU/IazImc/ZQA+slDBfhRDGYlExjg19UXWe/gMcl De3P1kxYPgZdGE2eZpRLIbt+rYnqQKy8UxlszsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ PVAiT6fnzIKmZAUCZAUSmwUJDK5EZgAKCRAiT6fnzIKmZOJGEACOKABgo9wJXsbWhGWYO7mD 8R8mUyJHqbvaz+yTLnvRwfe/VwafFfDMx5GYVYzMY9TWpA8psFTKTUIIQmx2scYsRBUwm5VI EurRWKqENcDRjyo+ol59j0FViYysjQQeobXBDDE31t5SBg++veI6tXfpco/UiKEsDswL1WAr tEAZaruo7254TyH+gydURl2wJuzo/aZ7Y7PpqaODbYv727Dvm5eX64HCyyAH0s6sOCyGF5/p eIhrOn24oBf67KtdAN3H9JoFNUVTYJc1VJU3R1JtVdgwEdr+NEciEfYl0O19VpLE/PZxP4wX PWnhf5WjdoNI1Xec+RcJ5p/pSel0jnvBX8L2cmniYnmI883NhtGZsEWj++wyKiS4NranDFlA HdDM3b4lUth1pTtABKQ1YuTvehj7EfoWD3bv9kuGZGPrAeFNiHPdOT7DaXKeHpW9homgtBxj 8aX/UkSvEGJKUEbFL9cVa5tzyialGkSiZJNkWgeHe+jEcfRT6pJZOJidSCdzvJpbdJmm+eED w9XOLH1IIWh7RURU7G1iOfEfmImFeC3cbbS73LQEFGe1urxvIH5K/7vX+FkNcr9ujwWuPE9b 1C2o4i/yZPLXIVy387EjA6GZMqvQUFuSTs/GeBcv0NjIQi8867H3uLjz+mQy63fAitsDwLmR EP+ylKVEKb0Q2A== In-Reply-To: <081837b697a98c7fa5832542b20f603d49e0b557.1729440856.git.lorenzo.stoakes@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 611C62000B X-Stat-Signature: h1964kdbi34k68eweo1amp3kewgu88as X-Rspam-User: X-HE-Tag: 1729520001-472413 X-HE-Meta: U2FsdGVkX1/ljFG6mePZrs9SiObvVcIUw35EVcjbBR9FDuHlGZ4tloLNxWj1oXvDvwy6Oru7yJ/TuHMVQOznGf9cchBudEQDQGcCMKay5AvoGNGNfgwJOGRWi67b0/7YkrIeGtkT1QNKPZbd4KjH7K0CfTekHScG+nczidWizOLjmsNEnHcHnBGvM45pp8DOXvgHLopjLny8FoLndTkC9f+yVeb1Jsdfn+YhfHcuVN5w5SJmEVbigCq3jZZ2Ux85NTRokpta7dcTJdh2tC+fxzmZ5WZUQBG5wZjUzM4852gnXyQs8N4u1WjXhzykLXOGwsj6HH5U4hogXtj0/zI+xxH75lHHBpGf7Y7mCCutGGZ4AD0uJWx+D0Z9HdOIfhu0nRiAcCOFNfdkEt2+ulUHA470oQ1tSEkgOB8pCyH5xxkRDCKJR0fFSvO5dqe89p1Ba09X6gpJd0gJvaXopP+pLKQ2xSTvGOboyVPHgmzGtzsjU+Uy9NtqsU+g21E08pAW6w5oUYSt1tGMGXUar7rjlwJFqTcjbhEKjOfhjPFgglW07nz26GRqElVyddDe3Id62D/WhQteIDcfllmV7Wdedfb6Gn6I8AKSeBj7DNON8CIAX4hyO6plAffjIWw4npeLBjQbT7nukYr/krHpdfMhQ4xY35HagLVN84til0SbLYxMS9uxqnzSTGt0+G6JpfbKmCDM+9xzzBID/YDJxrCh/O69SRN5GAOtTzazdAuPQ8So70mbHqW2XaNWvdkx4MnAKLxc7SrcYKTrBH//aVl9N4beQ8buW/OUDfTGCwLhKZJ0TeidthOXsU8ZIANUSFD5lxS/noqTZYTWWAtjg+xrGZPWMlAjIfgzvEksmyJlnPPwz9Hyi2ySAAt+LMPZe6flypn1lccAdOg8eJWWMIRUtRwtcOn/k/+roPkUAYQqvhwEW75FxS2d6PDMEapSN6vBs+8uXRhnUdylyNh7Hfl uqhW6QOT DM0R8YHvA9my1lW+oLFtDTtt9uGIvSc+r5ndomimHOnfqDsms9hMzV39syhUwLQbGXbSxAgGnTLcWD28V/7kEsCVVShdnRzGfe0AktJz+TVCVsq/gJsKo5iEwielm13ipwn8lwK5B3czxTD+jfsomgg4pYkdUopuRbzuU2znuoOnjzmQWMQZSUTvwJJgMZFbT7L0wL8gtUvzgqQw3DV1mWgoiS90YbYUr8VNnfRhHf8ruEsIHXGEKlidLD9sJcW+gMn86RNHPIK9CqqFIfvqERJHZw6FN/B5Es9Y15iP+HaCtztmyXXW5lXoGevIBcCNNdrgp62213pBJetfB52eaWH5Z5Ya8nGGSDOI8uaXGk09nIXQ= 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: List-Subscribe: List-Unsubscribe: On 10/20/24 18:20, Lorenzo Stoakes wrote: > Add a new PTE marker that results in any access causing the accessing > process to segfault. > > This is preferable to PTE_MARKER_POISONED, which results in the same > handling as hardware poisoned memory, and is thus undesirable for cases > where we simply wish to 'soft' poison a range. > > This is in preparation for implementing the ability to specify guard pages > at the page table level, i.e. ranges that, when accessed, should cause > process termination. > > Additionally, rename zap_drop_file_uffd_wp() to zap_drop_markers() - the > function checks the ZAP_FLAG_DROP_MARKER flag so naming it for this single > purpose was simply incorrect. > > We then reuse the same logic to determine whether a zap should clear a > guard entry - this should only be performed on teardown and never on > MADV_DONTNEED or the like. Since I would have personally put MADV_FREE among "or the like" here, it's surprising to me that it in fact it's tearing down the guard entries now. Is that intentional? It should be at least mentioned very explicitly. But I'd really argue against it, as MADV_FREE is to me a weaker form of MADV_DONTNEED - the existing pages are not zapped immediately but prioritized for reclaim. If MADV_DONTNEED leaves guard PTEs in place, why shouldn't MADV_FREE too? Seems to me rather currently an artifact of MADV_FREE implementation - if it encounters hwpoison entries it will tear them down because why not, we have detected a hw memory error and are lucky the program wants to discard the pages and not access them, so best use the opportunity and get rid of the PTE entries immediately (if MADV_DONTNEED doesn't do that too, it certainly could). But to extend this to guard PTEs which are result of an explicit userspace action feels wrong, unless the semantics is the same for MADV_DONTEED. The semantics chosen for MADV_DONTNEED makes sense, so MADV_FREE should behave the same? > Signed-off-by: Lorenzo Stoakes > --- > include/linux/mm_inline.h | 2 +- > include/linux/swapops.h | 26 ++++++++++++++++++++++++-- > mm/hugetlb.c | 3 +++ > mm/memory.c | 18 +++++++++++++++--- > 4 files changed, 43 insertions(+), 6 deletions(-) > > diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h > index 355cf46a01a6..1b6a917fffa4 100644 > --- a/include/linux/mm_inline.h > +++ b/include/linux/mm_inline.h > @@ -544,7 +544,7 @@ static inline pte_marker copy_pte_marker( > { > pte_marker srcm = pte_marker_get(entry); > /* Always copy error entries. */ > - pte_marker dstm = srcm & PTE_MARKER_POISONED; > + pte_marker dstm = srcm & (PTE_MARKER_POISONED | PTE_MARKER_GUARD); > > /* Only copy PTE markers if UFFD register matches. */ > if ((srcm & PTE_MARKER_UFFD_WP) && userfaultfd_wp(dst_vma)) > diff --git a/include/linux/swapops.h b/include/linux/swapops.h > index cb468e418ea1..4d0606df0791 100644 > --- a/include/linux/swapops.h > +++ b/include/linux/swapops.h > @@ -426,9 +426,15 @@ typedef unsigned long pte_marker; > * "Poisoned" here is meant in the very general sense of "future accesses are > * invalid", instead of referring very specifically to hardware memory errors. > * This marker is meant to represent any of various different causes of this. > + * > + * Note that, when encountered by the faulting logic, PTEs with this marker will > + * result in VM_FAULT_HWPOISON and thus regardless trigger hardware memory error > + * logic. > */ > #define PTE_MARKER_POISONED BIT(1) > -#define PTE_MARKER_MASK (BIT(2) - 1) > +/* Indicates that, on fault, this PTE will case a SIGSEGV signal to be sent. */ > +#define PTE_MARKER_GUARD BIT(2) > +#define PTE_MARKER_MASK (BIT(3) - 1) > > static inline swp_entry_t make_pte_marker_entry(pte_marker marker) > { > @@ -461,9 +467,25 @@ static inline swp_entry_t make_poisoned_swp_entry(void) > } > > static inline int is_poisoned_swp_entry(swp_entry_t entry) > +{ > + /* > + * We treat guard pages as poisoned too as these have the same semantics > + * as poisoned ranges, only with different fault handling. > + */ > + return is_pte_marker_entry(entry) && > + (pte_marker_get(entry) & > + (PTE_MARKER_POISONED | PTE_MARKER_GUARD)); > +} > + > +static inline swp_entry_t make_guard_swp_entry(void) > +{ > + return make_pte_marker_entry(PTE_MARKER_GUARD); > +} > + > +static inline int is_guard_swp_entry(swp_entry_t entry) > { > return is_pte_marker_entry(entry) && > - (pte_marker_get(entry) & PTE_MARKER_POISONED); > + (pte_marker_get(entry) & PTE_MARKER_GUARD); > } > > /* > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 906294ac85dc..50e3f6ed73ac 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -6353,6 +6353,9 @@ vm_fault_t hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma, > ret = VM_FAULT_HWPOISON_LARGE | > VM_FAULT_SET_HINDEX(hstate_index(h)); > goto out_mutex; > + } else if (marker & PTE_MARKER_GUARD) { > + ret = VM_FAULT_SIGSEGV; > + goto out_mutex; > } > } > > diff --git a/mm/memory.c b/mm/memory.c > index 0f614523b9f4..551455cd453f 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -1455,7 +1455,7 @@ static inline bool should_zap_folio(struct zap_details *details, > return !folio_test_anon(folio); > } > > -static inline bool zap_drop_file_uffd_wp(struct zap_details *details) > +static inline bool zap_drop_markers(struct zap_details *details) > { > if (!details) > return false; > @@ -1476,7 +1476,7 @@ zap_install_uffd_wp_if_needed(struct vm_area_struct *vma, > if (vma_is_anonymous(vma)) > return; > > - if (zap_drop_file_uffd_wp(details)) > + if (zap_drop_markers(details)) > return; > > for (;;) { > @@ -1671,7 +1671,15 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb, > * drop the marker if explicitly requested. > */ > if (!vma_is_anonymous(vma) && > - !zap_drop_file_uffd_wp(details)) > + !zap_drop_markers(details)) > + continue; > + } else if (is_guard_swp_entry(entry)) { > + /* > + * Ordinary zapping should not remove guard PTE > + * markers. Only do so if we should remove PTE markers > + * in general. > + */ > + if (!zap_drop_markers(details)) > continue; > } else if (is_hwpoison_entry(entry) || > is_poisoned_swp_entry(entry)) { > @@ -4003,6 +4011,10 @@ static vm_fault_t handle_pte_marker(struct vm_fault *vmf) > if (marker & PTE_MARKER_POISONED) > return VM_FAULT_HWPOISON; > > + /* Hitting a guard page is always a fatal condition. */ > + if (marker & PTE_MARKER_GUARD) > + return VM_FAULT_SIGSEGV; > + > if (pte_marker_entry_uffd_wp(entry)) > return pte_marker_handle_uffd_wp(vmf); >