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 F1BBAC8303C for ; Mon, 7 Jul 2025 15:41:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7A54F6B03FB; Mon, 7 Jul 2025 11:41:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7553B6B03FC; Mon, 7 Jul 2025 11:41:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 61CF66B03FD; Mon, 7 Jul 2025 11:41:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4C8966B03FB for ; Mon, 7 Jul 2025 11:41:12 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E66B0C01D4 for ; Mon, 7 Jul 2025 15:41:11 +0000 (UTC) X-FDA: 83637882342.20.67CCEDF Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by imf27.hostedemail.com (Postfix) with ESMTP id 1CCC740002 for ; Mon, 7 Jul 2025 15:41:09 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WcqS3bYi; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751902870; 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=nOso/rpbJ/NgC8eSTkPXsXfGalwkSd1v9wHI3jcpdtU=; b=4e1dI0whH7duik7OCmPyLWkWgk2u6N0nPGYzetcQJYH6MEKi1cYZQXbEyJkZRVVQsujpNQ h6q/H5rqk7/oCYigb0vpg/xF069hyMzbauCX21LDQIdvDM33H0tNSa/TKKkoLWXWGJEmGR YNfo6bpVepFgh7BOpBp7i64HPw115Vc= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WcqS3bYi; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751902870; a=rsa-sha256; cv=none; b=XiNgEi3UzeZjC4ob1m2aKdmswhubTg8af6uGdbDtfXPTJzdLs1xxeRHE7huWWDk3JBNe2N tr7vmg1BeV41+DLSdkNz+4554XSvVr5h135dF+M0ejU5jX62lTMXxZucDTRmlnZ8UJ3xAw ARavfaWITiGbpUYHQXS0DpGB/nPMWIE= Received: by mail-ua1-f44.google.com with SMTP id a1e0cc1a2514c-87ed676e631so2403273241.3 for ; Mon, 07 Jul 2025 08:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751902869; x=1752507669; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nOso/rpbJ/NgC8eSTkPXsXfGalwkSd1v9wHI3jcpdtU=; b=WcqS3bYihg87SLztDqKB/aRh+4hoATBzSJQPpuTJlSvDaLVlD653EmkbcmVYNGAIF9 aak3i893mTCA1M2rUp/1bUDtN45U3p/zWoC99gPEnNr12YFRLz31+2KGPy6af9dxGvdv 22y/aN7sjTocYCBTS0eRoYrauAl6VWYEIhkcwIiQSV0wMN8hJJS5+Y3YI3x3Scduv4Nc ibwN+Jrh5XEXwL3MB7qLfoGp0F9rk96mQwYFow6jIW9yRohPfW7KUqblgIAlbXAfLY3t 0f9jYlqOWrMBQbdzB6j3ksTtkR3he6+DsEOUbk5Gk4Zp/W4/UUcL0p5kC0JVDv/BnCYj gLGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751902869; x=1752507669; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nOso/rpbJ/NgC8eSTkPXsXfGalwkSd1v9wHI3jcpdtU=; b=YMAMMQP1TkT2eFW5IDwAn4276cSkPk/SYKxDrcArBkupMDUseAsRfWz8hLKzaCBHvN rYzXRnxPkMAuY1TZRroPx3u3ACL0l8HxQ4zJQ+Gnp+wyfhWvxmguPel+bSYK1SANWh9X Wkr7olNFesvbnLt6UqtTzZLBP5hLwzx0GwSB1mQNAP2l+sGOg0TmsmG1tYsT84ONrqLA n8ToVtGGoWSXf+xN9DA4BpOGVsAb+2+qE6nii9js8CvnMJaIP1RDlZNU5YVWRN4sLpfH vAUkF4nbC+7y6GKyJwzv1uyw9z4lQSyBwxmxEuVvBQJPI5DP/73hPVJ04+IKT2DRZPG1 snVA== X-Forwarded-Encrypted: i=1; AJvYcCUk0npKX/8s591wvdKdjkqHqjxv8OPipceBGEa1tA9xIRbwDn/m00QIM0GjJVjZCaW/Ul7OghLbWw==@kvack.org X-Gm-Message-State: AOJu0Ywxk8eh7xcQ+O1IFtkIa3UJUkMbNcxdwlIk3gQHrHOoTY0kGoyc 0+vWkn0piwK9LWkzwAC+DNdssPRfjqLkMOxFbS3F7tBgkKvOM16RPqmY1n4Agr473ped6phTX1E CJL4WPzXYnJUyr9cVnd3sU0nnw5rW9Io= X-Gm-Gg: ASbGncuh6tmLCR3Hg2BWYqCuLKJ4uCqtlLSnakmtkX0fvFjaKC+sVgZ7xCSnv7kTgEK Y9CxRy+lInArts5z3lz6fMvVkxiXefJdCsHRHcSNSe6kctUXyN39c5zkwJCtTVBK6m19Jh+LRBv ucJZdSiI/KysJGNhjWjcsgSAUV8YlMc4sRZ2vlDNZsxZSf X-Google-Smtp-Source: AGHT+IGSN1O8lQpDTPtqxgti1UrH4RQigSLZXKTO63RCc9Ii3DWxoJb0zhIToaSJqmxiqFJzc6TxB9dgjkrGQ0NAAJA= X-Received: by 2002:a05:6102:5813:b0:4e7:dbd2:4605 with SMTP id ada2fe7eead31-4f305bbfb6bmr5513792137.24.1751902868878; Mon, 07 Jul 2025 08:41:08 -0700 (PDT) MIME-Version: 1.0 References: <20250701143100.6970-1-lance.yang@linux.dev> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 7 Jul 2025 23:40:55 +0800 X-Gm-Features: Ac12FXzNubUaYli6QAPDLGtouYMN2VMWCTFnQ5iaenP8VAQuo6CN289JAgNG3X4 Message-ID: Subject: Re: [PATCH v4 1/1] mm/rmap: fix potential out-of-bounds page table access during batched unmap To: Harry Yoo Cc: Lance Yang , akpm@linux-foundation.org, david@redhat.com, baolin.wang@linux.alibaba.com, chrisl@kernel.org, kasong@tencent.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, lorenzo.stoakes@oracle.com, ryan.roberts@arm.com, v-songbaohua@oppo.com, x86@kernel.org, huang.ying.caritas@gmail.com, zhengtangquan@oppo.com, riel@surriel.com, Liam.Howlett@oracle.com, vbabka@suse.cz, mingzhe.yang@ly.com, stable@vger.kernel.org, Lance Yang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 1CCC740002 X-Stat-Signature: 879ra33k4btogmzbowffhqyfd3ppzmxt X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1751902869-551687 X-HE-Meta: U2FsdGVkX19Lk5v9uuuSkMHORFN7JacSzFdxjUhlBnISGTOQ1ydUxkn4523mP6eYPTRaOPYt/SlSpcZekJ5Jo1zuAR2bVdbBF4KqzYeDkZiMdzVkJRCqfWZ32lz0RhYIiFPuWz8t6I63RvUN8s0oehsi9Vlcp2HmmjXtPK+j1NJY0UhQZd45dmkv2Kz88qWN0ABQKWcnRpIkSlTeV5+8/Aq1k72HsZt3WyexNSJ9kAea69pq++p8YewVwvk9rTiJOIi88jjRZrI9HZoZUNEaUL3V5Rz0fyZNQU2hrAciGF1v3PO6aZ52jdSYM9vaqH0iIdW/R2TotwNstt7A/oZU/JNBxD/HJ5MzaigOFVqN+4zbay3l6eZZYXZmW2c5C/gHysMJ6EcnODTxJGh1//dxzEx+JKJL+bfLD5ZFUBc+NahO2ioTgFurTEjjzxJw6NB2ppTGg03GTrB4nxrBc7L9glALxb2Twasi5uNG9hv6FG1tKP7wXs+cve9iFrm9InMjC/1eABtzchj8spdjJHgoVtfTeHAXpBhk1YP5ObaAcwGBBE7yVrnk11+BEqkXgt+QpcMsx5skCYmtMNpQKRtP1nJXpSMgFGUxRQK/U+H4ugyWRiWcdtYLUGA33U2nFB8fyWCkivhsZLvglHzMzmhATA2LLGNsLWGILMHHY4keidh2+o842BmbojSSJTIdcDHMo58FWgoS1zCKBAafy40+KLVK+bxBwzeYWbH6ekKwOY1ASnQ1qLcGhYIZd6okJoAhyIBccwOP2nS3X0n+m6vmM/uCf/tMr0pUWFUvJykpYY4XmaiQ5B2SdDmEUAor4srngy4QFgR0TlZ4aFPeq1BLWjPB4v6Q3NMdH9nw5B2oL03JAlZgoaoU8axiU9LrpP9zLLC462rSTNDtCMfxsY2DwDnI4sztmposgPvaRculiC9Couiyb+60O0odeBZiEfenxU/zpdNsnj9LFV+cJDW erDtcj+M H3PzGrCJ6myd/P+SSFYAqhYpwoAoL9df6Vx/fUQehM0Kt9+5L33n5q1JW129AvWHMvY/T8BnZmjc0ZMAfDjEQ/hXmaCLjov0Uia79NttE4VAXybO3qg4xA7fsUSXJ0qz0+af+K+8hb2ta4xTxDmDxSaf6XCMbj+0Mn6gF/c8hbqXIHZW89OaDVv2bLfRf3lhM0UOxvl0kTQhM7MBqQW87P+HFhNwe5/m3Uz0giqzLcPW7/326R8XgTDxefMJkdurDdwXkEboIAwjCA2RhgupHIoeXSOyhzZbjoknbzuaaQq2ljtvurtk10NUrbkQ9V1jSOSr0X68ncSGBvxxB8X/XxvlZCIWK5AXyztr4jJv3YltQ0Os9t/mdBbzj7XoPg6DmmIsCj6TSphf/9RxpncLh2CpJ167nK96QJBdC0JV+0arOmG+58RQ2Uj5/Cg0PpDMyUnKALyq2NtIV2LbepiwmjUnCsHsSf69OSnnVqYGTDoPbGR+mS8R0GAKUAQ== 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 Mon, Jul 7, 2025 at 1:40=E2=80=AFPM Harry Yoo wro= te: > > On Tue, Jul 01, 2025 at 10:31:00PM +0800, Lance Yang wrote: > > From: Lance Yang > > > > As pointed out by David[1], the batched unmap logic in try_to_unmap_one= () > > may read past the end of a PTE table when a large folio's PTE mappings > > are not fully contained within a single page table. > > > > While this scenario might be rare, an issue triggerable from userspace = must > > be fixed regardless of its likelihood. This patch fixes the out-of-boun= ds > > access by refactoring the logic into a new helper, folio_unmap_pte_batc= h(). > > > > The new helper correctly calculates the safe batch size by capping the = scan > > at both the VMA and PMD boundaries. To simplify the code, it also suppo= rts > > partial batching (i.e., any number of pages from 1 up to the calculated > > safe maximum), as there is no strong reason to special-case for fully > > mapped folios. > > > > [1] https://lore.kernel.org/linux-mm/a694398c-9f03-4737-81b9-7e49c857fc= be@redhat.com > > > > Cc: > > Reported-by: David Hildenbrand > > Closes: https://lore.kernel.org/linux-mm/a694398c-9f03-4737-81b9-7e49c8= 57fcbe@redhat.com > > Fixes: 354dffd29575 ("mm: support batched unmap for lazyfree large foli= os during reclamation") > > Suggested-by: Barry Song > > Acked-by: Barry Song > > Reviewed-by: Lorenzo Stoakes > > Acked-by: David Hildenbrand > > Signed-off-by: Lance Yang > > --- > > LGTM, > Reviewed-by: Harry Yoo > > With a minor comment below. > > > diff --git a/mm/rmap.c b/mm/rmap.c > > index fb63d9256f09..1320b88fab74 100644 > > --- a/mm/rmap.c > > +++ b/mm/rmap.c > > @@ -2206,13 +2213,16 @@ static bool try_to_unmap_one(struct folio *foli= o, struct vm_area_struct *vma, > > hugetlb_remove_rmap(folio); > > } else { > > folio_remove_rmap_ptes(folio, subpage, nr_pages, = vma); > > - folio_ref_sub(folio, nr_pages - 1); > > } > > if (vma->vm_flags & VM_LOCKED) > > mlock_drain_local(); > > - folio_put(folio); > > - /* We have already batched the entire folio */ > > - if (nr_pages > 1) > > + folio_put_refs(folio, nr_pages); > > + > > + /* > > + * If we are sure that we batched the entire folio and cl= eared > > + * all PTEs, we can just optimize and stop right here. > > + */ > > + if (nr_pages =3D=3D folio_nr_pages(folio)) > > goto walk_done; > > Just a minor comment. > > We should probably teachhttps://lore.kernel.org/linux-mm/5db6fb4c-079d-42= 37-80b3-637565457f39@redhat.com/() to skip nr_pages pages, > or just rely on next_pte: do { ... } while (pte_none(ptep_get(pvmw->pte))= ) > loop in page_vma_mapped_walk() to skip those ptes? > > Taking different paths depending on (nr_pages =3D=3D folio_nr_pages(folio= )) > doesn't seem sensible. Hi Harry, I believe we've already had this discussion here: https://lore.kernel.org/linux-mm/5db6fb4c-079d-4237-80b3-637565457f39@redha= t.com/ My main point is that nr_pages =3D folio_nr_pages(folio) is the typical/common case. Also, modifying page_vma_mapped_walk() feels like a layering violation. > > > continue; > > -- > Cheers, > Harry / Hyeonggon Thanks Barry