From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793056843; b=11qWzUaKxR8lZ5ACpsD3EyAASyjezS/xtQ11fJ3BAxKXcH0ZZaaPrJT8TKOO0XNOfOH7 R+36hOkTi7fYIxuFQEgQjG432I7lXOov7NjcEENT88RiBpu0QYrS8zYsQWnmZSQHv0rDK +2H9xNEplL/iS852RT/3WNtdnZ5ovxUJbFxYVOOUzW/rIdRh/EPmlGAEN4QlrDHjeaByO SS10vxup+Yj7vwzXQB7TjNKqkcB2T6PQoE7wfMUEgJDt3LO3xERQn2QWA04v5ZUL/73Lm iAydkLowi0yRloK1Beye4lUYh1A5WZ4+mrl4Rc43jJ/ZRBpGOVHhH/yIxnS7S1UmhwQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793056843; h=Received:DKIM-Signature:From:Date:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:Message-Id:References:In-Reply-To:To:Cc: X-Mailer:X-Developer-Signature:X-Developer-Key; bh=6+gzYQp6lQKmnHV0p/bmjsvdO24Tz6PsMaqLI3Ia+mk=; b=jXunyw6/m842mlyhj+0TkI1glFqdlsMDVc6otEvNQzWQIynVSH1b3ESQ6PJ7iZydWJUG C7OjUO37pUFZ9zssCny/D1FgV5hNs34jEcLllsfonO+hDlj5/o/wyWoAqP8LIrLTIbVAs jr3AjpS7dipO2ANnRNsK+hIqkri9U2LsYhunsHt3tH8Bo57ZZs7KWBTFwUY3IZRvdsAzO OsoeEsyLE5s+867Pepdx4IJmZH6sZ8QRNwIwqSHtUg5A3fDTQa2pFaFgqbGIkRXAsZhzH H3bRzNPUVssY4SLq6fx84+fhKnzbUkJddwx3w2tq9rlefMot21VrEfAVDCNNJdOzS3Q== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=ZuADOBD7; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F748606A31A; Mon, 26 Oct 2026 23:20:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=ZuADOBD7 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5A58C1F01825; Mon, 26 Oct 2026 23:20:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793056842; bh=6+gzYQp6lQKmnHV0p/bmjsvdO24Tz6PsMaqLI3Ia+mk=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=ZuADOBD74c+0IEKa27h0VWHF4Fwh4hDQg2ZPJxGJ9JNaYFulNoe0acYVvsse86UEU rkJFSfGzcj5mO5BSB4+yKP3TepmOFSOBwO6PDS1TAGmzIDGdXt87IkwxD3lt+N6XHG 0sEuxBEc+CCzAqcvHYS4JvAH4pM63FvCeCa2FUKJtZg5u/2Y9DTpq/wLKsuDW9uPNN qkWlVUM316yrt9U3AiQI+82Ff064uf9aMs/PdMvtfO9X0FU4pbtirRWHo0GvBSnD+Y UbCn46/RAtNN2468Ds1AWN9cZmxRv6WMcTcCZaJOty8DA1lsi2IW7I/kkZbcvbttz+ 6BnIyAsK0ebjQ== From: "David Hildenbrand (Arm)" Date: Tue, 27 Oct 2026 00:17:29 +0100 Subject: [PATCH 09/46] mm/rmap: handle device-exclusive entries in folio_referenced_one() X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <20261027-fixes_core-v1-9-6f74bec9a5bb@kernel.org> References: <20261027-fixes_core-v1-0-6f74bec9a5bb@kernel.org> In-Reply-To: <20261027-fixes_core-v1-0-6f74bec9a5bb@kernel.org> To: Andrew Morton , Johannes Weiner , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Kairui Song , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Baoquan He , Baolin Wang , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Kees Cook , Peter Zijlstra , Jann Horn , Pedro Falcato , Hugh Dickins , Pasha Tatashin , Pratyush Yadav , "Matthew Wilcox (Oracle)" , Jan Kara , Zi Yan , Lance Yang , Rik van Riel , Harry Yoo , Alistair Popple , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Matthew Brost , John Hubbard , Peter Xu , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Oscar Salvador , Minchan Kim , Muchun Song , Xu Xin , Chengming Zhou , Chris Li , Kemeng Shi , Nhat Pham , Youngjun Park , Gregory Price , Joshua Hahn , Rakie Kim , Ying Huang , Jason Gunthorpe Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-cxl@vger.kernel.org, stable@vger.kernel.org, Josef Bacik , "David Hildenbrand (Arm)" X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=3201; i=david@kernel.org; h=from:subject:message-id; bh=5NdltRGk2kAjkCt9hyC9MFUfoZY1PF6asfKrPYTa0rM=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLLu35+iueVIn9OjO7wtfLkKak2XCz9N4ww92X/nDO9+i 5XTRG/s7ShlYRDjYJAVU2QJCr5v8PLlutpqNz5mmDmsTCBDGLg4BWAiErsYGWbOfT79VIbxxA7P +CsGvOL1Ts80rlnKrXwuuFz716ewL1oM//3PXspLrNSMmuPUV/8oU2bqgr9WEqcfnj0dFhb+3KZ TjhMA X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A page_vma_mapped_walk() can return non-present device-exclusive entries, but folio_referenced_one() passes them to PTE young-bit accessors that require present PTEs. We must neither call clear_flush_young_ptes_notify() nor folio_pte_batch() with non-present entries. For example, clearing the young bit on non-present PTEs can corrupt the entry: on arm64 PTE_AF overlaps the swap type, so clearing it turns a device-exclusive entry into an ordinary swap entry. folio_pte_batch() will VM_WARN_ON_FOLIO. Apply the same approach as the previous fixes to e.g., damon_ptep_mkold(): treat these entries as old from the CPU's perspective and obtain their young state through the MMU notifier. Skip PTE batching and MGLRU look-around for non-present entries, and don't modify non-present PTEs. Fixes: b756a3b5e7ea ("mm: device exclusive memory access") Reviewed-by: Lorenzo Stoakes (ARM) Cc: stable@vger.kernel.org Reported-by: Josef Bacik Signed-off-by: David Hildenbrand (Arm) --- mm/rmap.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/mm/rmap.c b/mm/rmap.c index 1131b76bbbc28..0faef46806e5c 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -924,6 +924,7 @@ static bool folio_referenced_one(struct folio *folio, DEFINE_FOLIO_VMA_WALK(pvmw, folio, vma, address, 0); int ptes = 0, referenced = 0; unsigned int nr; + pte_t pteval; while (page_vma_mapped_walk(&pvmw)) { address = pvmw.address; @@ -968,10 +969,12 @@ static bool folio_referenced_one(struct folio *folio, return false; } - if (pvmw.pte && folio_test_large(folio)) { + if (pvmw.pte) + pteval = ptep_get(pvmw.pte); + + if (pvmw.pte && pte_present(pteval) && folio_test_large(folio)) { const unsigned long end_addr = pmd_addr_end(address, vma->vm_end); const unsigned int max_nr = (end_addr - address) >> PAGE_SHIFT; - pte_t pteval = ptep_get(pvmw.pte); nr = folio_pte_batch(folio, pvmw.pte, pteval, max_nr); } @@ -981,11 +984,23 @@ static bool folio_referenced_one(struct folio *folio, * are. —they could be on active/inactive lists or on MGLRU. So the * simplest approach is to disable this look-around optimization. */ - if (lru_gen_enabled() && !lru_gen_switching() && pvmw.pte) { + if (lru_gen_enabled() && !lru_gen_switching() && pvmw.pte && + pte_present(pteval)) { if (lru_gen_look_around(&pvmw, nr)) referenced++; } else if (pvmw.pte) { - if (clear_flush_young_ptes_notify(vma, address, pvmw.pte, nr)) + bool young = false; + + /* + * PFN swap PTEs, such as device-exclusive ones, that + * actually map pages are "old" from a CPU perspective. + * The MMU notifier takes care of any device aspects. + */ + if (pte_present(pteval)) + young = clear_flush_young_ptes(vma, address, pvmw.pte, nr); + young |= mmu_notifier_clear_flush_young(vma->vm_mm, address, + address + nr * PAGE_SIZE); + if (young) referenced++; } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { if (pmdp_clear_flush_young_notify(vma, address, -- 2.43.0