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 93DC9C282DE for ; Fri, 7 Mar 2025 13:42:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF3A2280002; Fri, 7 Mar 2025 08:42:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EA59C280001; Fri, 7 Mar 2025 08:42:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6C52280002; Fri, 7 Mar 2025 08:42:16 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B7918280001 for ; Fri, 7 Mar 2025 08:42:16 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A4C87A8F8D for ; Fri, 7 Mar 2025 13:42:18 +0000 (UTC) X-FDA: 83194869156.14.A88E437 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf11.hostedemail.com (Postfix) with ESMTP id B6A3A40012 for ; Fri, 7 Mar 2025 13:42:16 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741354937; 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; bh=9pTD8BdKacRMxErn2MHbT9qW12CsVJ58IyyAS6Hc2Qg=; b=NydbtSg/Vnx5Tm5utmmYScv2BJkHUKSPuwEAGOFHdnx8BgMWqLR2AflQP3cGVTGIlnCPNW iRCuJL1WcwzbUs+lDsQH4g0KpoAPY3x4x/x/fkBQTqKHvzBpZTLSYmbQMAEMDeoqLXB+n5 MgWGTAVzdO5mfTl6LFYt6p+oVh/Hr90= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; spf=pass (imf11.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741354937; a=rsa-sha256; cv=none; b=7SQNpCR0SCeA1dK3dBiYY5Ea4popE3aEUlaQldALI1CcX1jFqCKURRNbalyhEHv7WoP1o+ 92rzx1kMkMZBCAy5F8XiIesw7I+rDcCxd4Y5DOXbmhn/lFmZB5J1pdXXg8apgis8RX8dLz PSQZ57xNEj1r9kR1ylPC3ctd1IErzsw= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 831931477; Fri, 7 Mar 2025 05:42:28 -0800 (PST) Received: from [10.57.84.99] (unknown [10.57.84.99]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F17883F66E; Fri, 7 Mar 2025 05:42:14 -0800 (PST) Message-ID: <03997253-0717-4ecb-8ac8-4a7ba49481a3@arm.com> Date: Fri, 7 Mar 2025 13:42:13 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] mm/madvise: Always set ptes via arch helpers Content-Language: en-GB To: Lorenzo Stoakes Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org References: <20250307123307.262298-1-ryan.roberts@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: B6A3A40012 X-Rspam-User: X-Stat-Signature: cgfa7kxb8387cprybp9um5inoc5j7kdj X-HE-Tag: 1741354936-776678 X-HE-Meta: U2FsdGVkX1+Ytm7rY9wO1c0DFQFyMn9CrANf3jEqjDEaCV5ajpL0PXpvXpo0bNXPPCdaqiJGc9SdoxnQzN7Wrkqg/MxqDakl47f7LHkiHOjBDgMYiC878PIPOjSd0sbMhWJEvsvJPm9fH2n8ZpmdFdbhSblGnUcTFYmU1n0XgWFT8L8vikpyWBymPlFaj4GDaMHkqsgeGf7mAbRW/arqheyKcYpRmSzSNcWk1HS8COZ6U+2CcD6uQiZ7wD3WcJdZs3ggYUkRymRBSAtnZ/OXcTnB+ZChMXjIw/LkqxGAol8TuC/x1iyBX8dfdsypOup0LlGi07hmLMHJFaE0wOjtIEU8aMGHHyrLTFsmTS/NF9k7f5bfwo0MoW3SZ7o866vQY75CV1Vu167hGKyq7/Feq9BE7aj6I5s8HixhEplp5q2RItyW+2obrk96J/Ji0mkx+5tqoJlILjOtjP//Ph1Gc0TqhVL69UEE4RR54K0XEozuRQAwKVF0r0ABLKsGaLWPJK/XHRZEO7Kyl2VNQdWMKcGdtI4Or1OB4SestkRa/PCxyXGekYH5qLuUQqNoJv2k8M3xFZ3Xq8P7PPU7bmlViBmDY5Ew/2BuIE0nu3Ltu4xrx1xNikUifMp8wWTGXIUtauyfTTIsX6tPBcMyDhL22kOeRG3kJ9Op8g4ws1ipYjsCSBv9ElmZlMJUIjAw6KiyhVi/gWW2vICgZ435lP4w/p/k75r3LZrCzkCnBi5B0W9jyKMtEInbYzWSdaYPzs6qFAlFNNY+YQY+qxBDYUwNyGClntbpJqTLwBxpg9l/6pa2UnD2GG2aIRvZI+gUgVLKRChLJ66QPZJCy7UcjxYU3a9b6czQ7Z0AeMginPBJKXmgXb7aa8TXXPbwgaWNjz92r/sIE3BsNmh+w1NMF8wOUy6Fg3kgfv3h+T2U77UjafdxtTaipc+ZWAW9NsSJaOG/mJGYkZElGsMIAe9dVs7 R6liw6UX hy1460STyFfkwUvOKv9YuLMOKxvV9WoiHWUPs1nV2ciyUXI+Kz2L+wV6iUIPwE0jTiyDYD/ww7aycCftqyVaA6lpamNRHln6tKz0DPR6e99qFfOnAf1pr6RxA9JQX4d/NEihnYCUoWjzv+10SIL2tYKwh5geEAghqT86Iw+e6FVt4ouhFHOzWYyfbYid3Ia6txAY+ujNhBXxHGk8JWKQl6TDA2WX/TRc2/Opn 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 07/03/2025 13:04, Lorenzo Stoakes wrote: > On Fri, Mar 07, 2025 at 12:33:06PM +0000, Ryan Roberts wrote: >> Instead of writing a pte directly into the table, use the set_pte_at() >> helper, which gives the arch visibility of the change. >> >> In this instance we are guaranteed that the pte was originally none and >> is being modified to a not-present pte, so there was unlikely to be a >> bug in practice (at least not on arm64). But it's bad practice to write >> the page table memory directly without arch involvement. >> >> Cc: >> Fixes: 662df3e5c376 ("mm: madvise: implement lightweight guard page mechanism") >> Signed-off-by: Ryan Roberts >> --- >> mm/madvise.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/madvise.c b/mm/madvise.c >> index 388dc289b5d1..6170f4acc14f 100644 >> --- a/mm/madvise.c >> +++ b/mm/madvise.c >> @@ -1101,7 +1101,7 @@ static int guard_install_set_pte(unsigned long addr, unsigned long next, >> unsigned long *nr_pages = (unsigned long *)walk->private; >> >> /* Simply install a PTE marker, this causes segfault on access. */ >> - *ptep = make_pte_marker(PTE_MARKER_GUARD); >> + set_pte_at(walk->mm, addr, ptep, make_pte_marker(PTE_MARKER_GUARD)); > > I agree with you, but I think perhaps the arg name here is misleading :) If > you look at mm/pagewalk.c and specifically, in walk_pte_range_inner(): > > if (ops->install_pte && pte_none(ptep_get(pte))) { > pte_t new_pte; > > err = ops->install_pte(addr, addr + PAGE_SIZE, &new_pte, > walk); > if (err) > break; > > set_pte_at(walk->mm, addr, pte, new_pte); > > ... > } > > So the ptep being assigned here is a stack value, new_pte, which we simply > assign to, and _then_ the page walker code handles the set_pte_at() for us. > > So we are indeed doing the right thing here, just in a different place :P Ahh my bad. In that case, please ignore the patch. But out of interest, why are you doing it like this? I find it a bit confusing as all the other ops (e.g. pte_entry()) work directly on the pgtable's pte without the intermediate. Thanks, Ryan > >> (*nr_pages)++; >> >> return 0; >> -- >> 2.43.0 >>