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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7EA92C88E77 for ; Wed, 16 Sep 2026 11:05:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36B956B0088; Wed, 16 Sep 2026 07:05:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31B4B6B008C; Wed, 16 Sep 2026 07:05:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 230636B0092; Wed, 16 Sep 2026 07:05:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EB53C6B0088 for ; Wed, 16 Sep 2026 07:05:53 -0400 (EDT) Received: from smtpin10.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 96DF5A5D15 for ; Wed, 16 Sep 2026 11:05:53 +0000 (UTC) X-FDA: 85219345386.10.2C22ACD Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf20.hostedemail.com (Postfix) with ESMTP id EB4E81C0008 for ; Wed, 16 Sep 2026 11:05:51 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20260515 header.b=ZA3RLk6f; spf=pass (imf20.hostedemail.com: domain of ljs@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=ljs@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1789556751; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=DYEbp3NDbWCNlMXuaXTXLtCtA8T9knTbdyJ+6diMaPQ=; b=TteTnFbu22wpD/QWgMLK5fUzrFud3YHzPB+lZhTsxsQXXK9nzWbR9Mfb2BcOKTfP364wN0 jxJFYmWoejFcCKqH0/fhhHOVgiEy+TphkndPdFMQ4EuATCBw3eVkZzGDyNVWhmDP8BNGUH Dyf0kLQ7Fe1A1H8mD4sIcH1t6WKoxDc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20260515 header.b=ZA3RLk6f; spf=pass (imf20.hostedemail.com: domain of ljs@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=ljs@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; a=rsa-sha256; d=hostedemail.com; s=arc-20220608; cv=none; t=1789556751; b=xNYnZnq761PJVAoIso/fZWC914GKPXyZyyZCVOxNN+ZPOCfnSKYsuWiqtchmqmd9eAcdNl OYTHH45BE7BGNv/6aJoGHu/J/rjN7S9rGkPQuYL9Nx19sHB6ysUzrrXWIx5o+n184Pu6HR 2JIV8h+7ke9SCkUI8SRmXvxrsdX90KY= Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 6D1DB60234; Wed, 16 Sep 2026 11:05:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6C8831F000FF; Wed, 16 Sep 2026 11:05:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789556751; bh=DYEbp3NDbWCNlMXuaXTXLtCtA8T9knTbdyJ+6diMaPQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ZA3RLk6f5n/v3mZ9/7OVo3fJZHY0MAmzZ+5QFDzF2dod2OVpfNO6VBCctrHbqs6i6 A/QtImdtfHw2cCEDIPmoCTtVHReumt29NbdSIpeuBgCLyBoDtDwPfaXMazedOhoX/G xUCHOkCuN+DFcInc+PYB4dEITaNa32GPcF38QLDt86dWtyjq24SF+APGC9KGPXBAeV HK7u/iWI8SG3LfUfgZjSo576F9X4Lcdb4gkOls9qCv5wqRXYZluBJa2QhwM4459Wij VlFlb11urNHILrRaDFVb+teLrwyUBU1kFqXYtyLwDv1g7VC6Ykd3JyM/iQDzEOg0sv B3dZ+rP/Kb/vg== Date: Wed, 16 Sep 2026 12:05:43 +0100 From: "Lorenzo Stoakes (ARM)" To: Gregory Price Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, akpm@linux-foundation.org, liam@infradead.org, david@kernel.org, vbabka@kernel.org, jannh@google.com, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, ying.huang@linux.alibaba.com, apopple@nvidia.com, peterx@redhat.com, jgg@ziepe.ca, sashiko-bot , stable@vger.kernel.org Subject: Re: [PATCH v2 2/2] mm/madvise: use vm_normal_folio_pmd() in cold/pageout PMD range Message-ID: References: <20260912034833.2952750-1-gourry@gourry.net> <20260912034833.2952750-3-gourry@gourry.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260912034833.2952750-3-gourry@gourry.net> X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: EB4E81C0008 X-Stat-Signature: xrey5e7oozr3irimhiweck1nmtr91qcy X-Rspam-User: X-HE-Tag: 1789556751-162483 X-HE-Meta: U2FsdGVkX19STTRtc1AFR5kqEuIJr9yiCWafpnchm6NI0eFwY55Ny/CGjWvSX0+MznXuKh9Rve+D2n2SryJQsKHzCrjLUW8kwBy4jp6PyKTY8nhYMI2YYium9r7ukas+99HkWaO+9z7hdlXcjjRVpt4i7LK3A49RXqraV6zz8y90lbsWlx0uJMdmTw+l47/F6c73ADCSeXJcxJGVN/65rmYJ5o2er1ro344nG39I8b59GhgUjG1MwYW/MQDfIMIlTUnsxErimvQnxxD5jvYF4VJWN9U/gG2L2K1vZ7fo+uU6N0RWPagbUt75XutJGWCAFElVJ3ZJIvF0mbIPTjQ3tC6hgq2ms1nd16Z/C+ZB2URhUsl/HCMzu4bQywevaHBbzzae/eGm0iJmiqtgRPhzxGN3y5h31RRxrX6kykatsYvWfLwV3MMnW2hekzqzA4HE+RP8av9JsUjYltzuiUSuo+wFeOv1zrCOCKUiLflJ/PHyLmrHQZ53rkg7tcTr/PSiILbhnkJkiuHnONfpEQhjOHk9ZyxeqqODxsKspRxVJYyWv9tsLwA8Hy7ZF2xCeDju70PBYd/4zQQoWhyi/nNpTRXbrFEzK17dBWJ9hY6UY1D7v2h1Lu9r6gbtglDCicNSiCKG1XswTuBr8uambY+Z88z8ISIgXea8oqI55RAsT0NCoCKK055ZmlkeiRvWBxDQkmHA1VcOzvO0YVbuaBUKct3SmVY9dbe5OgZ/Fh+n7NHlFkCBHJBNG8kLCmkcRrg9xV4jAukfXF/ugVGE+q+l/8mNPeGbbWGWGFhG6qlYYo0QMz1Ps5xb7dD2ZFfAfVeoTJku1FNXkTUvfhmhV8Ccc6+sWSQxdBEYCe6/2fOGXUsmPyZwPNPxZNNkun2j4hH/Sz70fLllyMOLf0dRmoONNd7gbq+oeOEaNJY2Bom+we/0SOWmg2PnZYck8dYNDb+bIWfWeWMIk0co8bFYBoB lA8Rs1wH VXMVPIay5sBmztSGWvx1x+zzkjNQZlpnv0eF6LLmRv6nJvArrlIeoeqhFChRKCozHyUlqXL5TaJ/BUMtUk60c2RjSvDS07Mg5JE8DU/KimzpALRwNZwg6VsJ5LyUwi1nLzfmE7Rw00Sj8ksjXJH4577y8pLdHbyCnrw1TesIJ5Q36S+D8JsiY+21UdkYruTqCRtII/PmpveChkYTWpqRTsPrP4wNbBSmYxPlDZkm3BadV8/lHPf15RucDZZynLSg3TSOcswz+0MBHvnGX/JCJH560Ju+Cdh2yKqDKKqnyEUsxjpsBD6Tc82cWdREDdtG6mkU6BaqsRorTpBNT+S88PQ2SxTtpywI7kMDc8EHji95oCDkw5txdbXuwxRMm8oNt6ig6nmbVlTi4lKncLCh/qF/9ckD+IL6q2v+vuhuU9BMU8L3OGxscBJjo1lhXUhAMkDHo+MnL46WGN79OVc49k4Yyz7Rfw14zxGTdLiiQLsuNF4fDYp7wjEBBvFecJiMNPUttZIMFcnNP4MY= Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Sep 11, 2026 at 11:48:33PM -0400, Gregory Price wrote: > mmap a VM_MIXEDMAP region whose ->huge_fault installs a PMD through Gosh, shock, horror! VMA_MIXEDMAP_BIT sir! :P (It's fine it's fine) > vmf_insert_pfn_pmd() - mshv_vtl_low does this, and needs CAP_SYS_ADMIN > to open - then: > > madvise(p, PMD_SIZE, MADV_PAGEOUT); > > With a stand-in module for the driver: > > BUG: unable to handle page fault for address: fffff587c0000008 > RIP: 0010:madvise_cold_or_pageout_pte_range+0x410/0x9b0 > walk_pgd_range+0x52b/0xaf0 > __walk_page_range+0x6a/0x1d0 > walk_page_range_vma_unsafe+0x8e/0x120 > madvise_pageout+0xb2/0x180 > madvise_vma_behavior+0x46b/0xa90 > do_madvise+0x108/0x190 > __x64_sys_madvise+0x26/0x30 > > Nothing validates the pfn on the way in: > > can_madv_lru_vma() rejects VM_PFNMAP, but not VM_MIXEDMAP > can_fault() *pfn = vmf->pgoff & ~(mask >> PAGE_SHIFT); > vmf_insert_pfn_pmd() no pfn_valid() check > pmd_folio() pfn_to_page() -> unpopulated vmemmap I definitely suggest checking out the small series [0] I sent which changes how these kinds of semantics are expressed where I... ugh what I missed can_madv_lru_vma()! Damn it. Noted as a follow up :) [0]:https://lore.kernel.org/linux-mm/20260914-b4-mmap-prepare-vma-flag-sanify-v2-0-7d9781ed5361@kernel.org/ > > Even with a valid pfn the path is wrong. The mapping carries no rmap, so Isn't a non-rmappable page not a folio? I mean the fact that vm_normal_folio_pmd() returns NULL is kinda saying that :) > folio_maybe_mapped_shared() sees mapcount 0, and the walker goes on to > folio_deactivate(), or folio_isolate_lru() plus reclaim_pages(), against a > folio this mapping does not own. > > Use vm_normal_folio_pmd() and skip on NULL, as the PTE half of this same > walker already does with vm_normal_folio(). This also filters the huge > zero PMD, so its separate check is no longer needed. > > Fixes: 3c8e44c9b369 ("mm: mark special bits for huge pfn mappings when inject") > Reported-by: sashiko-bot > Closes: https://sashiko.dev/#/patchset/20260817220810.1175596-1-gourry%40gourry.net > Cc: stable@vger.kernel.org # v6.19+ > Assisted-by: LLM > Signed-off-by: Gregory Price (Meta) LGTM in general so: Reviewed-by: Lorenzo Stoakes (ARM) > --- > mm/madvise.c | 7 +++---- > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/mm/madvise.c b/mm/madvise.c > index f75a9d139980..fbb72ab49aa6 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -395,16 +395,15 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd, > return 0; > Oh God! This function again! > orig_pmd = *pmd; > - if (is_huge_zero_pmd(orig_pmd)) > - goto huge_unlock; > - > if (unlikely(!pmd_present(orig_pmd))) { > VM_WARN_ON_ONCE(!pmd_is_migration_entry(orig_pmd) && > !pmd_is_device_private_entry(orig_pmd)); > goto huge_unlock; > } > > - folio = pmd_folio(orig_pmd); Again I'm wondering if pmd_folio() is just a code smell in general? > + folio = vm_normal_folio_pmd(vma, addr, orig_pmd); > + if (!folio) > + goto huge_unlock; > > if (folio_is_zone_device(folio)) > goto huge_unlock; > -- > 2.55.0 > -- Cheers, Lorenzo