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 18330C7EE2A for ; Fri, 27 Jun 2025 06:55:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B131A8D0016; Fri, 27 Jun 2025 02:55:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC4098D0013; Fri, 27 Jun 2025 02:55:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D9B68D0016; Fri, 27 Jun 2025 02:55:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8F1E28D0013 for ; Fri, 27 Jun 2025 02:55:49 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1A2911225F5 for ; Fri, 27 Jun 2025 06:55:49 +0000 (UTC) X-FDA: 83600270418.12.CAC685B Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) by imf03.hostedemail.com (Postfix) with ESMTP id 33D2E20003 for ; Fri, 27 Jun 2025 06:55:46 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TgepBzgz; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.47 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=1751007347; 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=AonkeL2UG9zbG1SpDxserAwv5MTYfIP9basgeC0vKE8=; b=BVzEh0iA2oWhr85nbO9dj+b4PMG7VUwwonKEwSoYdd0Y0Wb3YmhlMUPkA1FXzw1oZs1BSp NGpxAsJjtr68/MKacnqv8CVymQTPPlWupuNN6zK8HcyikbF86/svrx1/1t0pdw3LHsp6Zd xyeD4HA0ugW6HZXbuG+2ttsXB/s8FhQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751007347; a=rsa-sha256; cv=none; b=qP8zjJN4YgxYQ+XTgQ1fB48sfUq5T/KWEO/0BO4/mjbu0qKkvbfmI8hLAJayzh4NWUHF/s /xIGmbyZrjCV2S7EZ33UNypBGkNzSHqWuB+kfXL7mQ3qjtcU9MBSzPnYWQzCCliFKyMJII ltu0G2kISbEdmiNHzEj51H/HpE3pArA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TgepBzgz; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.47 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vs1-f47.google.com with SMTP id ada2fe7eead31-4e7949d9753so487637137.2 for ; Thu, 26 Jun 2025 23:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751007346; x=1751612146; 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=AonkeL2UG9zbG1SpDxserAwv5MTYfIP9basgeC0vKE8=; b=TgepBzgzffAmzRkTx3MrkUQDCNt7IqbFbdh/vXnkaKEj9YyKg3que1vY6iQ7W3OXue RERhHPCDnQlBaXnCQooC2+BKF39KKhPEbhsfwjn+QW/253XjEXkM6MXDht6Pnjx0SVOo fQJcAVmMbmDTsna5s7qo1tbOKnLHpePG+h3qUg5XJ3LY3EAWpI8vzn/KORTIkmj9Ifkg JpeCN4WwnpCj5YGbqnWwpz49RRtZJ4XcJ9Si7E622REr5G7qhLh9dx31u0+SbHhYhxrc VMUDcRzmUvHbS3TdziJx2omYwxd6gd9tlnI/jDeTj9UHhqiDTY6oPyHFrQ7yy6WTXmqE Us8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751007346; x=1751612146; 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=AonkeL2UG9zbG1SpDxserAwv5MTYfIP9basgeC0vKE8=; b=uG8WKEBPVhd2AFo3k+cuIvIk1d9urSW5etDuNB9EnG84uWRqJ7Kf3krezrL1RLMQlB jl8zUrVl5IEE5crkQXKChHF386PCZY1I8mF/vDUTfL/zZn5sHG2nKARDPAeom7Oy3+ZX a/H8R1/Fibm19aDt9ZRcks3vxc9kXlY0//tyAbDxU8Zc3tHDdp8OAaCXPubjHa5eMwrb yn3DAZx9DWebi3+b76Pg3YSL8U1B2A02oBlXzOx+YwWaJM2Mp0OXsOINmQpxX5KjEuzm NoLbAHvrQcVC1/k0unpE0wFjkbRA2rn/C2sjCqlOtKSYnb+47KiSSbLh5rzTe9u0kA2z 8D3Q== X-Forwarded-Encrypted: i=1; AJvYcCVz/Uj1EbRR9wKCHlLOBi2E7FpJYls/jLv+iZ2Q0fXwNgfKQVo1ts+3wVZMWBfC7RW5iSRiH/Tv5A==@kvack.org X-Gm-Message-State: AOJu0YwahIfgts+8scERcol/1l/qiEv6Ph4uk9MugT+WAz7CEL/gTxY8 uR1hMeQDqNrvqEhWOApgqFX+T1oVaC33hqCmoJxPVZ4VbMMW5wvGr7uHQl8nXTQ9+KOGpmXLapQ g+hxw708Uo/zMTfgApgPuJBIbA24m+z8= X-Gm-Gg: ASbGncvgmQlSittDbEhELmdR5hPfdEEyAJngJwRNN3LKkxjcp0Pvrho+Y/weeBut+nG kxJbdTDYXJR2tAOvsp7xRB4UAz08d29lPJjxXzvCzbKSxtLmbh7eepiPsgqFp+4XiCZo/ldrHAZ 2rrJ3zc60kv8bzmgwZZEM6VwiaxCyzSfreA6mlWHMAzoEYf7nBGecijQ== X-Google-Smtp-Source: AGHT+IHID72abIG7KO9tY0TMUT/7rvTScdoSDX7SF0tYvqk7dfZNu62uOYY7u8MoIAmAQhMkN3cJSxhZsgMz1pZQ9R4= X-Received: by 2002:a05:6102:919:b0:4e5:acea:2dec with SMTP id ada2fe7eead31-4ee4f6a6083mr1641746137.7.1751007346178; Thu, 26 Jun 2025 23:55:46 -0700 (PDT) MIME-Version: 1.0 References: <20250627062319.84936-1-lance.yang@linux.dev> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 27 Jun 2025 18:55:35 +1200 X-Gm-Features: Ac12FXxvwUg1I8DIO0v6b56l2GT04XdFM5Ht5dpca7QYboGTabvmi5kE5vPkba0 Message-ID: Subject: Re: [PATCH v2 1/1] mm/rmap: fix potential out-of-bounds page table access during batched unmap 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, stable@vger.kernel.org, Lance Yang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 33D2E20003 X-Stat-Signature: mpsekkygcjpf6giic7g1z6t8ketazw4x X-Rspam-User: X-HE-Tag: 1751007346-586976 X-HE-Meta: U2FsdGVkX1/YKc6S5ifvtMHxjtkk64P6DE2lBMVVwfQIOtbDMxgnZnW9rcrwUGNWvQq799LZ0kxr7j9vfVZeilNqbUn/CbX/2MFSZh+sMK1NJv4OZakbWN3ZL0a4FlWxolnoSqRyxHzhx6RGMYoWEhhkbrDAMlNSzeSzhlEZgFTW3eEmBWFu9+fQ+05cx4pPREl3VLQbI5TgNoKZcfrz7qC4XmEyHbuQO/hC4HkiK36BodFI9F1/y/BNG6hhL6q09HxAta75ciF3pD9ni6P/2yuGF6IkHsHvImeUGIF803kv3EOzaUslH6TkpWSKtEeWAQGXXfrv0Iitz7ekSMVf16H6T5IgaiQtzOSWn8a/IrXktFZQPDomwgZWgHP8G2useLG8gwaa3tpnUY3XEHZhkHLSKaG+lEjHiKUBKXQy3PCUlW1PvvMGQdEpOI+j4vz76ihZU2AhYnQryEmLRsk3MXJX9p3vNsA0pF+PPsQRxaQrv1aUzc9+DfZqcACzNa+URgEw8G2FMzAhqW9MM6eccipzLm5n3B1ZqsMEwWkw4rjdVQR6lMtOSRPibrc0QTNLgeFTFNCsNe+A1FUUyERXzebmIkCsJxtCHRspopwnaOapqEutOcZ+XfBcMA5IsEOpLJlUscCX/DuRYhtgMg0l2jS9NKgG2kIKfmhKlE59XCDdR0ERTWqSqZgFXEHZRBwgA87F94OsHnB3D51AIM8vaFMP+b+JO8LbQrzFVTkZvxLKp76XoL+/Ex3NwXkROMsgvcWajYf5mgSkL/r2fybbADtdBUPZDy7gsEMYBpLq3N7Yp2G7w6Et7KOLYfVfbMCJWjw6wUfx7Ip8H5SvNl1Bm/eRoq3daWOtJQJqxI0UO8STZdAKkkNhR7W8fu1aSrDmKuGgYqlvLoQauuiSUVPXU3v3JCvGbqlPOPbQEys9QY3X0M+R8EO7mRSG2Z6BLPh5JSS4IvR5IzutMEFsvqG bnBfDH3n RCvD/RDb8iR56nRGKJQaSgFm/6BHeiSTo3qvPMr5vFJOot3nzIr7QIgBdVTFbddOWzl1RgPqjh9CttBHq4hMUwd7C+5Y9Npw4IuppZYizzLl7ZsIQuArCvvEza0cIUshc8IEhAQPP2aKqxN7xRUR45ivSxoV3CfmVebHBPkuPsNV4A95B1W57Kl1UFIoRhANjL0JrTbzP6vb5m/rPU1j5BbZQUxI8VZTmxIAR8ZrjxdmBjMvKv3Po59UP/vePMbkMoR4n3crJvGYem55xZc8uBMJBvxExNPhQw9RznkPR2yJC0AfREe8KRC9xj51i0Q5If6rpdtBTJ8jW/aZI56qMVxo1GZ/AjKtblBMlD9waPZtMELY9C13HFjW/tcItMx1O2WVOI2F250k4WuiLPCwl6MAJJWe6b9/lAFLzV7iH1f/kadTDGb3KVw5r1ptnZxmszyyvkM/dfqWyX6BD8klz3kgAyaEXnge+3KvFOOD2gIy7bdJPs4Pxf2VZPQ== 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 6:52=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > On Fri, Jun 27, 2025 at 6:23=E2=80=AFPM Lance Yang = wrote: > > > > 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 startin= g at > > the last entry of that table. It would be quite rare in practice, as > > MADV_FREE typically splits the large folio ;) > > > > So let's fix the potential 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 sca= n 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 u= se > > folio_put_refs(). > > > > [1] https://lore.kernel.org/linux-mm/a694398c-9f03-4737-81b9-7e49c857fc= be@redhat.com > > > > What about ? > > 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 spans across two = PMDs, > particularly after being remapped with mremap(). This patch fixes the > potential out-of-bounds access by capping the batch at vm_end and the PMD > boundary. > > It also refactors the logic into a new helper, folio_unmap_pte_batch(), > which supports batching between 1 and folio_nr_pages. This improves code > clarity. Note that such cases are rare in practice, as MADV_FREE typicall= y > splits large folios. Sorry, I meant that MADV_FREE typically splits large folios if the specifie= d range doesn't cover the entire folio. > > Thanks > Barry