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 36D18C7EE31 for ; Fri, 27 Jun 2025 05:02:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B7ABA8D0003; Fri, 27 Jun 2025 01:02:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B50A18D0001; Fri, 27 Jun 2025 01:02:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A66798D0003; Fri, 27 Jun 2025 01:02:34 -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 96F078D0001 for ; Fri, 27 Jun 2025 01:02:34 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3ECE61D7100 for ; Fri, 27 Jun 2025 05:02:34 +0000 (UTC) X-FDA: 83599985028.17.ED3F6D9 Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) by imf27.hostedemail.com (Postfix) with ESMTP id 6660240014 for ; Fri, 27 Jun 2025 05:02:32 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=V4eDRiLg; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.41 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=1751000552; 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=yEyVocKnMCps8xWL9t4dI9N+dVYbiLKomAWOYOvHcuE=; b=mdURxIIa2URwvblrMNkZGsgf6Q2sgH6p/3bzDK41lDc/PVMITOz/UrLRcJPItO0Ent3HQ0 +8epHIZG+IDvywpkGO6GqDHX9vJgR+ityvMIaUMYfG2aGUWnRaVOtwIXcaGny+mNxJ/PIt lIFGghlSKdGniK1BvZVSeMl0Ivxde+o= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=V4eDRiLg; spf=pass (imf27.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.41 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=1751000552; a=rsa-sha256; cv=none; b=IUBaVg+shf/53XmOSYSY1Py26i4PvxbOF55+g9iQs56KcPnQXyxrRCDwiwlMx9HcsW00xx zfzFxOhXix89UZMp02RNpPcVyu1b33MyEg0pzk0wWLrr9fVUDhohHaNeof0d9DYsSOEv64 3UQRwF5lYzXmxPzcqb0qtUZLxacOxgc= Received: by mail-vs1-f41.google.com with SMTP id ada2fe7eead31-4e2b5ffb932so378319137.0 for ; Thu, 26 Jun 2025 22:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751000551; x=1751605351; 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=yEyVocKnMCps8xWL9t4dI9N+dVYbiLKomAWOYOvHcuE=; b=V4eDRiLgvSgVB9rIzVvy6/YN7Kl/W3nH7P9ttxKqHTZ/z01i92aZWGKLEzgmZJz9Rk P4eJYudkM3CbJro+ay8VbwrKEe22r3aR3X5w+lWU3d10bJLVep5F3HqF9XlYeS9V3Zrf LDvw6n3j6ELPiSm1PWiUO6FWFRHij8fXzm5dVl2hKjDrCS+SllirTgZjLEOMYGoxEz50 75rYKcjhlEYGPuU8qCRxh1y2n6dt7CYqLmmZyFqs6m4767b4ztp/bn7s9DZ6Sk2iZLD7 +Pb+t76RUpbU26JfI25LzSRzjwjmeIDAEZ7WfnB666Q1t3g9QxHBaP0tUFpfjKWjPt8N 4S6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751000551; x=1751605351; 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=yEyVocKnMCps8xWL9t4dI9N+dVYbiLKomAWOYOvHcuE=; b=Ak2voch8PNG7FWZi/7xCy+8zaefrzuChyKqDNZG7tfbGIBWbJNKFqEd6br925E4R6W gUBn56/AKVg6FMmLwJpZn/Y/2v3r7dQz9WcsyMyPcDAVNu+Fwvx7FmkoZocuzdM/GZQf KKTd2uWTOvSrJCzZDjdoesocaNZdnw7uRu7vfI67i3tssA10ZLn4Q4rWLcVtD5UP+5Cw 9Ji+1B2eqTKNDGIoaTWMUbON7DVNMNe/OJR3OYf7+oPAgNrLjdTfZnlDXYa0tfejJlBv S5+JDgbMiF97ml+v0wrTo3o1fds1wPEV2jAp+kGTOrekZgi27OyS2oITTZSEhlT4AXws b0oA== X-Forwarded-Encrypted: i=1; AJvYcCWmFLDT6295JVPe/vCsb17tjpfW5ebqxZij2yJc09HcqLuPOa4ew6KPWAdBgn3YD2XzAM0nLWKzgg==@kvack.org X-Gm-Message-State: AOJu0YxJr3B46VLUiqIjK6n94RLodaT5qVKzmX3gHiYU+R+HA45dF3KK 3EEGOOquxCs5GNmckD+/vTBaQeIM8g+7ngzFfg/XUVllaDHSlqDlmZkJodyQfZ67ePxCf7GXPyh R9MK+ChR8fkl9sr9x7PiZ58lB94r5jVI= X-Gm-Gg: ASbGncuIH1TPInChhbtMYhit89wc2QACY1G+kv0LpI/PKZXSM2pao/wewHH0LKWpf1t wCxjXZ6jv4dhWeKQLNwRVtAwvq9JkKw5pKz/whQFxWrxj1yoCqt0vSzmLmfagXjbvI8ahQ2VMFM kuWk78ouDbc/QnzOPHYwTS/OtEYHZWypuTtdcqisRbSW8= X-Google-Smtp-Source: AGHT+IEvQnJ4QRqSGP2qB52UDJLc95vE2WmXbirVa0pHP16TPMhIb8u9XNfVSz15xZVnzrhavxHSi3E8vgSvANL5nrA= X-Received: by 2002:a05:6102:149e:b0:4ec:c50c:399f with SMTP id ada2fe7eead31-4ee4f692664mr1810518137.11.1751000551372; Thu, 26 Jun 2025 22:02:31 -0700 (PDT) MIME-Version: 1.0 References: <20250627025214.30887-1-lance.yang@linux.dev> In-Reply-To: <20250627025214.30887-1-lance.yang@linux.dev> From: Barry Song <21cnbao@gmail.com> Date: Fri, 27 Jun 2025 17:02:20 +1200 X-Gm-Features: Ac12FXywX0xekxUXC52Wn56ratHki1z8cUWVFBJGFLSfqAnwCvDX9QWChaOYL38 Message-ID: Subject: Re: [PATCH 1/1] mm/rmap: make folio unmap batching safe and support partial batches To: Lance Yang Cc: 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, harry.yoo@oracle.com, mingzhe.yang@ly.com, Lance Yang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6660240014 X-Stat-Signature: if754bpny6dfsfyd8eysxfgxeshdtjw1 X-HE-Tag: 1751000552-234555 X-HE-Meta: U2FsdGVkX1+rFGb7Tw4OmG10rNbriJrMfwF7fniqNdCdE4afBOgMGo7APD3l6KbddQ7gL3XgUM5Zz1WbkkUliRWSv8HCNaR7MRDsqxZZj+X65Rqx3PbcwCgROUdJqLG2hP3srnig72BqwfiGBAx44NAgkinP1M1mTxcMTysHyha8aPtl4VcLMIDjG9Mo9ccc0XKdkx+jugFb700E4ZW9AGOqUQnD8DjOSqRLXoZGJzijxLGLlN3hAJDQXSdMB2T7s720FgrJt/UCuwrJpLrTdFl6mRiH9Pg3ljsNj/MiNrT0so5frWR7Pjv5dPTFC71Utze/OZKnQiboMJU4rWisv2GEZ2qjT8BcQrcgp5vCiuLACmymVJe+FI/X2vRfi8Nul8pWosk3sF0d/d2vKHN42r57QIf44/kXxHIixe90CGKzWSfkQ+syGGLV6wiXyvMOVokqwJMvgiUhzR2X77d5cy0WfcS3qVmHJvLWsp/FnEzKmYUOjlR9BqD/HHG21QZ4dQj0gYe2SXLNsNkiKqPlC+hl09m0rQSMLqW5qVGOHmWPHHNrNFDnyOYQWW5MeZ2AJiELNihe2OmY0pjGLzgowDFEFXN8ZLgJI/Nxv+l0K1OexzJUpwEZj/AmQz08n1U5ljxTl2zIZ3Sz4tTuGvr48PPbmbiRVCaKj33h1hc9cbF4FjyyjO0180KVa53dnri0LIz7zilI86mru0/ZkZt6oTLWq+ml1r8HE5thJ72DwONlA354FhbSNa6N9eRCYzWSCdlaY55bYz1HGvhG+f6WJQakHuVv3rveL8y6qxwwVYPILuVHrmsGRfAKqISOkidGWYMkgxE90RGOmoMbqVGafeLJoZyF6bpmmKzMXb4y4rvOmJfGyMKXIo4YpOKmqHTI8yLbihd/rd95Y1NfE0JQ5JxbLY6aegS6iKwL5zRpwCvkbYrn3IXHueYf31MgLFgVQJeNZIbVMN7u5a4khyV Dh9VnO6+ gJkF5vp9HvJG25XA8zBu9isB8iSjen/8V30X70mTDKkNgZ19/FsdZsg+5PiUtpdzZigKvPs/QdxcUpiKfErGwhTdVngBpsvCFwmI3wffZTZgJaAEFx9z7XD0NALe+qdmr8W6avcL1Cw7UZwwaY6TWWmdtxkHwPVj4lSxbVHf3U+nSqSxpre6zQ+XGwWgzIYeas7CRiz6FC9T3reqnfvfu2BxKKU1TYdcTLSHA2iPJ/z/dJdmgfDqCrrLfaB2oek90H5FbUw1T+wHEIyP5mrXRHWZHvpDEhxC71cCXue3JYkzGOckuoSyFoilNFzHK72+SD6UaaQ/rzFFtTpJfvTfmuQ05i3JHGChHNDtHO81SLdg6CBL8e8Dkq9shyqD9oWMxBVKk2yRq5O7zy6BRz69Y+2yiiR1vB2Qs8c0Gd5iX5RYxOls2ER/w3HfNb5CSYNT8mcUI55i1bEYxwWZdKxaEiGyK+xR/vNe0SOyAdgSMs/rIq2pVtR6eobylWg== 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 Fri, Jun 27, 2025 at 2:53=E2=80=AFPM Lance Yang wr= ote: > > From: Lance Yang > > As pointed out by David[1], the batched unmap logic in try_to_unmap_one() > can read past the end of a PTE table if a large folio is mapped starting = at > the last entry of that table. > > So let's fix the out-of-bounds read by refactoring the logic into a new > helper, folio_unmap_pte_batch(). > > The new helper now correctly calculates the safe number of pages to scan = by > limiting the operation to the boundaries of the current VMA and the PTE > table. > > In addition, the "all-or-nothing" batching restriction is removed to > support partial batches. The reference counting is also cleaned up to use > folio_put_refs(). > > [1] https://lore.kernel.org/linux-mm/a694398c-9f03-4737-81b9-7e49c857fcbe= @redhat.com > > Fixes: 354dffd29575 ("mm: support batched unmap for lazyfree large folios= during reclamation") > Suggested-by: David Hildenbrand > Suggested-by: Barry Song > Signed-off-by: Lance Yang I'd prefer changing the subject to something like "Fix potential out-of-bounds page table access during batched unmap" Supporting partial batching is a cleanup-related benefit of this fix. It's worth mentioning that the affected cases are quite rare, since MADV_FREE typically performs split_folio(). Also, we need to Cc stable. Thanks Barry