From nobody Mon Feb 9 19:30:55 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC38F1DF960 for ; Wed, 29 Jan 2025 11:54:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738151687; cv=none; b=GgsS6LhDOsYl9xXasjXFicr4H1mrq1t26ovFefrj9oUxtSTdFbsspW28D84E3kC7nhCwCBJcciZhI5hLqbYG6IKI0Wdvw1jnltBc7Gm192OXMM8G7X5Asya4RG1u4ut+CA/+ZuHBnhOr1EY4ZLCB+GiuV7/8Cz1XDoho9eqrRrk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738151687; c=relaxed/simple; bh=3RX1C3dSti0Y2JUqODIhfRDdkayq20GNG0HByNlQRYA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SJAHnfQhLFARo7NnNPcZaBbjqYPgeXalb9YKLcV0kGGRSlhQ51EJw2ajTHIIX1XZf3YkJhxNh7/tNTzePbAOHbZuxhlzOTonOWug6L66z2rh9czviWHArOc03lRG4MjVXMiQ5nHcFjoyUwDl1eXJ1TZZJ0YBCa3K8yHjQBsKdfo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Gb0AFx00; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Gb0AFx00" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738151684; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=mNM6Zw+nv5CKX0FXtzXMADzAxRUJZ/HteqC2IEBjnh8=; b=Gb0AFx00hvqDSKO8mnHFf8JR1IO47yryW3Y5vQB6yJQF1oUKXgDx/6nMAjpD5m8bDyj9MG Wc3REuPcyRZgydF/RYu7nrJGiqgw5MeRHyKW7wwvr9JbJQSKQL3FeiUPcRf5qT4GAk20SQ fskMEhA1hBB2TY/nifET64ZyLILd7fA= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-460-EylURdCNOhaYwUtRVe1Kbw-1; Wed, 29 Jan 2025 06:54:43 -0500 X-MC-Unique: EylURdCNOhaYwUtRVe1Kbw-1 X-Mimecast-MFC-AGG-ID: EylURdCNOhaYwUtRVe1Kbw Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-38a684a0971so3067292f8f.2 for ; Wed, 29 Jan 2025 03:54:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738151682; x=1738756482; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mNM6Zw+nv5CKX0FXtzXMADzAxRUJZ/HteqC2IEBjnh8=; b=DpP8fgacKRPknF65SGafirUe17hhirwqYh8B/qDzLu68Wl4rg8p81fDgTHZsjXPkFN TD75zAbwE+PP9AC4B5mkxSzLr2h/utC7O2JclJexe8MDbz9n1nGWpTHdfTRux6RzkW5m WKyvWf2Qo6zT4sv20m6bKtUbI5J78rpPSkeksYNO/URb8eWJ3JLqsdiqwqa1KkBxsFbX 8Ev7sItXrXqqibP/0PnUZHQMFEY65Sah6Jz521D7Jb/QMK0nDZig66J+P/CXTR/yT5pC uJhqg7LwZdp2V5IaUtDjgaXKuc9YV9Wue68wk3XBYVP06EXneIFhR1XtmuWsWpQrnnav xSiw== X-Gm-Message-State: AOJu0YyPQxgYQZNO5H3c+8SawhLRqv7mpXPmzj6LX5aQGTsguxEpQDhy 2/UjFoW0cTk6XLvhGzSCMYHujJq4tXCXhth3NrNIyZxiB/cEDOC396Iizn10mHApy9vK7WSwO1Q 7j44SNfBJhfTHM8HVP+mLlXlwQIa5s+fwrMwiQDaiWjwW3fNSqF5xU6/Y/7zWrVEYCMDH3tHDNX bDWzo7IwHQ3FPpTAxBjRClAauRUy0wku1DnI2J45ShmfaV X-Gm-Gg: ASbGncutl7rrFs0yK9jCymfy5KrHghocwYbq9UPvhpUY0B8lMXh5Icu2JphKBfUttBl Oum+32Spr0/11mmnvoKFy3pZWLDH/6x0SsyAY+uDVJL2cwBpZEbdRg0nPgzPY36Ur7g4RqUIt8b a06Yn6vAha+O1KLHOPrXJMRxjIR7MOAcJFtAcbaafqs7zL7ESj2NSoA+Cnm7E5I0qv6ncGOEeEn WP9xoEuvlAcVMSwbj26NMKUqrpKACfv8vFwGEy71ghWU/+kGlBGQGuSR6XAVfismzR4pmZgGvSG 37cyZBJTu1whb9272pE+6cGR6mNNLVeZox0Xi3dRdulWH/zr2KMwx1CzVgcE93fkkw== X-Received: by 2002:a05:6000:4013:b0:385:f631:612 with SMTP id ffacd0b85a97d-38c5195f2e5mr2415004f8f.17.1738151682181; Wed, 29 Jan 2025 03:54:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IEfVb9Gb5/TQQdvQH0d8Y86brLumLHRijGlRqbPqwAUyE2LkrZ873cAyk0+z1AQr8yjahg13A== X-Received: by 2002:a05:6000:4013:b0:385:f631:612 with SMTP id ffacd0b85a97d-38c5195f2e5mr2414952f8f.17.1738151681703; Wed, 29 Jan 2025 03:54:41 -0800 (PST) Received: from localhost (p200300cbc7053b0064b867195794bf13.dip0.t-ipconnect.de. [2003:cb:c705:3b00:64b8:6719:5794:bf13]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-38c2a1c4212sm16316119f8f.87.2025.01.29.03.54.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jan 2025 03:54:41 -0800 (PST) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-doc@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-mm@kvack.org, nouveau@lists.freedesktop.org, David Hildenbrand , Andrew Morton , =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= , Jonathan Corbet , Alex Shi , Yanteng Si , Karol Herbst , Lyude Paul , Danilo Krummrich , David Airlie , Simona Vetter , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Pasha Tatashin , Peter Xu , Alistair Popple , Jason Gunthorpe Subject: [PATCH v1 10/12] mm/rmap: handle device-exclusive entries correctly in folio_referenced_one() Date: Wed, 29 Jan 2025 12:54:08 +0100 Message-ID: <20250129115411.2077152-11-david@redhat.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: <20250129115411.2077152-1-david@redhat.com> References: <20250129115411.2077152-1-david@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Ever since commit b756a3b5e7ea ("mm: device exclusive memory access") we can return with a device-exclusive entry from page_vma_mapped_walk(). folio_referenced_one() is not prepared for that, so teach it about these non-present nonswap PTEs. We'll likely never hit that path with device-private entries, but we could with device-exclusive ones. It's not really clear what to do: the device could be accessing this PTE, but we don't have that information in the PTE. Likely MMU notifiers should be taking care of that, and we can just assume "not referenced by the CPU". Note that we could currently only run into this case with device-exclusive entries on THPs. For order-0 folios, we still adjust the mapcount on conversion to device-exclusive, making the rmap walk abort early (folio_mapcount() =3D=3D 0). We'll fix that next, now that folio_referenced_one() can handle it. Fixes: b756a3b5e7ea ("mm: device exclusive memory access") Signed-off-by: David Hildenbrand --- mm/rmap.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/mm/rmap.c b/mm/rmap.c index 903a78e60781..77b063e9aec4 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -899,8 +899,14 @@ static bool folio_referenced_one(struct folio *folio, if (lru_gen_look_around(&pvmw)) referenced++; } else if (pvmw.pte) { - if (ptep_clear_flush_young_notify(vma, address, - pvmw.pte)) + /* + * We can end up here with selected non-swap entries + * that actually map pages similar to PROT_NONE; see + * page_vma_mapped_walk()->check_pte(). From a CPU + * perspective, these PTEs are old. + */ + if (pte_present(ptep_get(pvmw.pte)) && + ptep_clear_flush_young_notify(vma, address, pvmw.pte)) referenced++; } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { if (pmdp_clear_flush_young_notify(vma, address, --=20 2.48.1