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 31D75C3ABA5 for ; Tue, 29 Apr 2025 18:33:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E4C36B0005; Tue, 29 Apr 2025 14:33:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 792D86B0006; Tue, 29 Apr 2025 14:33:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60F736B0007; Tue, 29 Apr 2025 14:33:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 427536B0005 for ; Tue, 29 Apr 2025 14:33:29 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id F022EC7721 for ; Tue, 29 Apr 2025 18:33:30 +0000 (UTC) X-FDA: 83387929380.24.57EB06D Received: from gmmr-2.centrum.cz (gmmr-2.centrum.cz [46.255.227.203]) by imf09.hostedemail.com (Postfix) with ESMTP id D607414000F for ; Tue, 29 Apr 2025 18:33:27 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=atlas.cz header.s=mail header.b=VLJC+HyF; dkim=pass header.d=atlas.cz header.s=mail header.b=VLJC+HyF; dmarc=pass (policy=none) header.from=atlas.cz; spf=pass (imf09.hostedemail.com: domain of arkamar@atlas.cz designates 46.255.227.203 as permitted sender) smtp.mailfrom=arkamar@atlas.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745951608; a=rsa-sha256; cv=none; b=BNZzDI94MoQbIhxQX++TcjedqNya2dUSCAIpJyNXPqBH5q2ZgidnUl7Y/TgdXqleyQxQpP Sn+EXHjdMC/Xm12ywkcA8LrYNj4lBvVpxDeE6UIlQA/fszH9LVyUmmsm/DYSnEujhrCaD1 QDdwHw7qLMqndW0W5gJMwl6TV4JLX5o= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745951608; 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=UviKfPN5+v0SBsUoC5z5Ae18skRFLQGuYZPCRcGgySE=; b=f7vIQyqK95ljWJIVXBYFIURolvJnuodhY+vsufvwppL88hOwYSVHAW4kI2uGJkSKD9htNO C5kUN2rNExXol4VT0cOQhba295d5g7oXg5+gb1BV2doxLia7KKBv7bigK/kcSK4vF8EIam ZAmlC85zcp4mG0D1WjfmvmMDhStA1eE= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=atlas.cz header.s=mail header.b=VLJC+HyF; dkim=pass header.d=atlas.cz header.s=mail header.b=VLJC+HyF; dmarc=pass (policy=none) header.from=atlas.cz; spf=pass (imf09.hostedemail.com: domain of arkamar@atlas.cz designates 46.255.227.203 as permitted sender) smtp.mailfrom=arkamar@atlas.cz Received: from gmmr-1.centrum.cz (envoy-stl.cent [10.32.56.18]) by gmmr-2.centrum.cz (Postfix) with ESMTP id 6196E2024EF6 for ; Tue, 29 Apr 2025 20:33:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atlas.cz; s=mail; t=1745951604; bh=UviKfPN5+v0SBsUoC5z5Ae18skRFLQGuYZPCRcGgySE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VLJC+HyF8Ci9BhNPmmddMHWHXwizgNMDVwq8yNrQ40DgTeYpIZWT5vgzzr8bNlzMM I0Ofq1qs3rcpiHrI7p9+wlGOd8LSApiXvcuv6JFO88p/wmpab93gw+W7ieumV0Mma9 qneZtSJwLQQWQNWVgMTcKsk4j7Ok+4PBC0sHrY68= Received: from gmmr-1.centrum.cz (localhost [127.0.0.1]) by gmmr-1.centrum.cz (Postfix) with ESMTP id 5CFE119D for ; Tue, 29 Apr 2025 20:33:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atlas.cz; s=mail; t=1745951604; bh=UviKfPN5+v0SBsUoC5z5Ae18skRFLQGuYZPCRcGgySE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VLJC+HyF8Ci9BhNPmmddMHWHXwizgNMDVwq8yNrQ40DgTeYpIZWT5vgzzr8bNlzMM I0Ofq1qs3rcpiHrI7p9+wlGOd8LSApiXvcuv6JFO88p/wmpab93gw+W7ieumV0Mma9 qneZtSJwLQQWQNWVgMTcKsk4j7Ok+4PBC0sHrY68= Received: from antispam31.centrum.cz (antispam31.cent [10.30.208.31]) by gmmr-1.centrum.cz (Postfix) with ESMTP id 5B92BD8 for ; Tue, 29 Apr 2025 20:33:24 +0200 (CEST) X-CSE-ConnectionGUID: ZnyxlZOzR/+6KfKYimKROQ== X-CSE-MsgGUID: aP3vmKuER+yqDqXruykamg== X-ThreatScanner-Verdict: Negative X-IPAS-Result: =?us-ascii?q?A2EXAACAGhFo/0vj/y5aGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUAJgTgEAQEBCwGFJIRVkXEDiiSBUoYzi2uBfg8BAQEBAQEBAQEJRAQBA?= =?us-ascii?q?T+ESAKLNSc2Bw4BAgQBAQEBAwIDAQEBAQEBAQEBDQEBBgEBAQEBAQYGAQKBH?= =?us-ascii?q?YU1U4JiAYN/AQEBAQIBIwQLAUYFCwsNCwICJgICVgYTgwKCMAEDDiOyXHp/M?= =?us-ascii?q?xoCZdxwAkkFVWOBKoEbLgGITwGFbIR3QoINhAc4PogegmkEg0OFepgmUnscA?= =?us-ascii?q?1ksAVUTFwsHBYEmQwOBDyNLBS4dghGFIYIRgVwDAyIBgxN0HIRmhFAtT4Mvg?= =?us-ascii?q?gJoSSBAAwttPTcUGwaWeYNkBgFyHEMJZcVPgkODHIEJhE6dFTOXcAOSZC6HZ?= =?us-ascii?q?ZBrG6kagW0Bgg8zIjCDIlIZzB92PAIHAQoBAQMJgjuNYYFLAQE?= IronPort-PHdr: A9a23:EznWjBwgt9t0dS3XCzJFzVBlVkEcU1XcAAcZ59Idhq5Udez7ptK+Z xaZva0m1gGVAN6TwskHotSVmpioYXYH75eFvSJKW713fDhBpOMo2icNO4q7M3D9N+PgdCcgH c5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7Ovr6GpLIj8Swyuu+54Dfbx9HiTezf79+N gm6oRneusUIgIZvJaY8xxXUqXZUZupawn9lKl2Ukxvg/Mm74YRt8z5Xu/Iv9s5AVbv1cqElR rFGDzooLn446tTzuRfMVQWA6WIQX3sZnBRVGwTK4w30UZn3sivhq+pywzKaMtHsTbA1Qjut8 aFmQwL1hSgdNj459GbXitFsjK9evRmsqQBzz5LSbYqIL/d1YL/Tcs0GSmpARsZRVjJOAoWgb 4sUEuENOf9Uo5Thq1cSqBezAxSnCuHyxT9SnnL406003fo/HA/b3wIgEd0Bv2jJo9v6NqgfS vy1warSwDnfc/9axTXw5Y7VeR4hu/GMWrdwfNLLx0YxCwPFlEibpoP/MDOTyOENsHWQ4u16W uK1iG4osQRxrSK1xso3kIbJmoYVxUrf9Slj3Ik0JMS1RUhmatGrDJVerTuVN5dqQsw8WWFov j43x6EJtJO0cyYExpAqyh3fZfGJfIaE/BLuWemNLDtlmX5rdqyyiwiy/EWh1OHwSsm53VRWo iZZkdTBq3AD2gHT5MWBV/Bz/V+h1C6A2g3S8O1IP0A5mKrBJ5I/3LI9lIAfvEbDEyPuhkn6k aGbel869uS29+jreKvqq5CAO4NujgzzM6IjkdGlD+siKAgBRW2b9Py51L3k4EL2Xq1HjuYzk qnFqJDaItkbprKhDw9VzIkj7xG/Ai+p0NQdhHUHN1dFeA6fj4T0Jl3COuz3Aum5g1Swijdr2 vXGMqf9DZTMNnTDkbHhcqhh60NExwc+zMpT64xUB7wBOv7/RFH9ud7CAhI7MwG42+PnB8981 oMaV2KPGKiZMKbKvFCS/OIvIPODZIoPtzbnMPUq/eLujXsjll8GZ6WmwZoWZGiiHvt6O0WZf WbsgtAZHGcQvgsxVurqhEeYUT5UfHm9Qbg85i0gCI+9F4jDXIWtjKad0ye8G51afnpGBUyUE Xf0a4WEXO8BaCaTIs9njzwFWqGtS4ok1Ry1tw/61aBoIfbX+iECspLjztd16/XJlR4u7Tx0E 9id02aVQm5unWMIXzo20bt7oUx8zFeDzKd5j+VWFdxU+vNJVBo1OoTAz+x7DNDyXBjNftCTS FapWtmmGy0+Tsotw98SZEZwA8itgQrd3yqrHrAYjKaLC4Ip/aLcxXfxO9xxxGrB1Kkkl1UmW NdANXW6hq5j8AjeH4rJk0Sfl6a3eqUQxS3N+3mZzWqIok5YVBV9UbvKXX8BfEvat9f56V3YT 7+oF7snNhFNycmYKqtFctHpl0lJRO//ONTCZGK8g3ywBQqSybyXaIrlZX4Q3DvSCEcaiQAf5 3WGOhYkBienvW3eCCZiFVX1Y0Pj6eV+rmi0QVcuzw6Wd01hy6a1+hkNiPGdU/8cw7EEuCYkq zhsBFiz0NzZBcScqQd9eqsPKe86tXtOy2PV/yx8OpCtKap4j1gSO1B7tl3v2z1tB4lAmNRsp 3QvmllcM6WdhWtMaynQ45n2mb6ffmDo/xmqYrT+003a2c3Q8bVZu6dwkEnqoAz8ThlqyH5gy dQAliLEvv33 IronPort-Data: A9a23:N/qkOKm9jgtfR9H4nE5jgvLo5gy1J0RdPkR7XQ2eYbSJt1+Wr1Gzt xIdXmGDb67ZMWP0KdgkbNiyo00HuJ/TnYcwGgJp/ysxRFtH+JHPbTi7wuYcHM8wwunrFh8PA xA2M4GYRCwMZiaB4Erra/658CQUOZigHtLUEPTDNj16WThqQSIgjQMLs+Mii+aEu/Dga++2k Y20+pC31GONgWYubzpIsfPb8nuDgdyr0N8mlg1jDRx0lACG/5UlJMp3Db28KXL+Xr5VEoaSL 87fzKu093/u5BwkDNWoiN7TKiXmlZaPVeQmoiM+t5mK2nCulARrukoIHKZ0hXNsttm8t4sZJ ONl7sXsFFhzbsUgr8xGO/VQO3kW0aSrY9YrK1Dn2SCY5xWun3cBX5yCpaz5VGEV0r8fPI1Ay RAXAAILfwCHtcWk+vX4FMpipfUiKerRG7pK7xmMzRmBZRonaZ/GBr7P+ccBhXE7i8ZSB+vbI cELAdZtREieJUcSZxFNUs14w7rAanrXKlW0rHqcv6k+5mHJ5AVt1LH2dtHHEjCPbZwMxhnE/ DibpwwVBDkTDIeBzBmY30jvl/bjhBPhRZMRHbi3o6sCbFq7gzZ75ActfUGqqP//kEm0VshDM GQd4C9opq83nGSvT9/gT1i9pVaHoBcXWJxXCeJSwAiO0q/85wefG3hBQDlcbtAvqM4xQ3otz FDht9/gGz1jmKeYRXKU6vGfqjbaESwUK3ISICwJVw0I5/H9r4wpyBHCVNBuFOiylNKdMSrsy jqOoQAgiLgJy80GzaO2+RbAmT3Em3TSZlJroF+KAyT/tFw/O9PNi5GU1GU3JM1odO6xJmRtd lBd8yRCxIji1a2wqRE= IronPort-HdrOrdr: A9a23:z7hBMaCXzOhgliXlHemh55DYdb4zR+YMi2TDGXofdfVwSL38qy nIpoV+6faUskdyZJhOo7q90cW7LE80sKQFhrX5Xo3SPzUO2lHIEGgK1+KLqAEIWRefygc378 ldmsZFZOHNMQ== X-Talos-CUID: 9a23:zePfZGzsVcSYE9vKMsYLBgUmHNE1dk/63k2XYBGbB0VYSbi2c3iprfY= X-Talos-MUID: 9a23:OxUBrgqslPxuIsBZZ9gezzhab9ltwLmDMgMciLkfi9OZJC95PjjI2Q== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="6.15,249,1739833200"; d="scan'208";a="110742250" Received: from unknown (HELO gm-smtp11.centrum.cz) ([46.255.227.75]) by antispam31.centrum.cz with ESMTP; 29 Apr 2025 20:33:24 +0200 Received: from arkam (ip-213-220-240-96.bb.vodafone.cz [213.220.240.96]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by gm-smtp11.centrum.cz (Postfix) with ESMTPSA id DFBCB100AE133; Tue, 29 Apr 2025 20:33:23 +0200 (CEST) Date: Tue, 29 Apr 2025 20:33:21 +0200 From: Petr =?utf-8?B?VmFuxJtr?= To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, Andrew Morton , Ryan Roberts , linux-mm@kvack.org, stable@vger.kernel.org Subject: Re: [PATCH 1/1] mm: Fix folio_pte_batch() overcount with zero PTEs Message-ID: <2025429183321-aBEbcQQY3WX6dsNI-arkamar@atlas.cz> References: <20250429142237.22138-1-arkamar@atlas.cz> <20250429142237.22138-2-arkamar@atlas.cz> <2025429144547-aBDmGzJBQc9RMBj--arkamar@atlas.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: D607414000F X-Stat-Signature: 38b9zxdjy5t63auhy86aiajpfzj5i4uf X-Rspam-User: X-HE-Tag: 1745951607-376613 X-HE-Meta: U2FsdGVkX18PuVPYyOlF4eKfJnnwayBlt0JglmWCXKB3NjiOBOVcEsPUuPrHezC5MK3SHBXz14UGjziIpEfyyOg8Gg5B3ZZDJShRHGZo8BrXbqBWuHkZzg7pYQ0C0zvb+4JgRjurpS+iHOWzYaA52AhfjjgUIyVsc1xYub7pHv0w8TePMMa1Jq47LS/82yrApnestaIPZNdcWawWpfW1IEvelExUN/eFXny795G0ni8r2sBN/tdxIJOS6MM41f7YN+ri/C8mIU+JZGfjkcHqLEcS/9Yz05u+D0mJHnnETNq3dqevna8siB1o3qnT9tYqDRaL0po+9pg1fs0kEtplYjafSyE4xwhlUBsXOi04Ube6JsYaM3jwJR9VDMroKaekqXMOOPKQigiWolZ33H+SqqVuYKS5wnH03FeB2Zs2EIkd4fUo7EGso4QRMHKfsvwyKjxqJB0i8EPAvGtfOaepPXKAmml5kMLSwnG9nZT9ngpvjO4KvgUbc2luMld+3C71EWyFn2QvabrxWPO+pUph4Zho9HVmf18EMmJxNnPNVSQEWM8UpI8Hkk7mFVjVTDgMMk32xQd3rRujXcYF8/GXd91sYY7hHjwbIGbbdDlEAPwA+9M1rBT5oVPzxLzwVSOs+Ixcrp+N/8fr7RfwQEa/cy+GNhufMcW5EBQFcHXENP497gSaKAw/U6Wij0hh4UIFLLWkuQzGRLO26Al3Jc7N5EqHYChlcaCcJ1ZKGBEBlm1pi/RrDBjfVmf3qd+GlYk8W0au/psRXZ8ACfuGgpubH51zVDfR/UjFGsN+kZIxdvGxpqj0XwEj4oOyo6SJBPj0Z/aiQ5qURAt19MMtc9aIZFIksib7+6KiI5K2hKidN7O221YEjKpumDyzEcpnPiL5sXeaPH386SjZ1zFM9O9v3YtHoElhVWiPPIo42DUutr6ZVjDNFpAnuWBLvrc8LTjpOWFIT0bMn49P7iZbpc8 +n0jjXDW niVgWCUM2wecy6aEwS8f+y/15tIkcNnteGtsduHLxZKryD4EUvazF+8pMdqC0pePlunxDkxwwa9U7JsUvcLggb/O2SqPuKnJjiJWmbSsEpfHjRuSEc8fwJi/9Akyd/pxrKDnQJcQSnmY3hoRpoDNjhRtcXPETV0/vr3P04N90Jykp7C/tR62VuFwMPN1FvP8yoITcipEN78eHSS0QKlP8mDn67QDnNl58YDzFh4rfTNz1kOwUR7S4yfQ2+X+z1f4UcpPxO6c+cRz97w0NQhDWuPdbdFMme8pN6+iz07LJj6AVsdCUIljZQfL2qCYwMaKFHp83/la/lXNGFB0i+rdAzA+ngljz3xYiNZSvy5Fv5/JZ4qWf7rkSc0SOPGSYpYcydnq4YVDJ7drajUUZXH7/FFAyhNXz/WUByOpwDx4rG0Y5qcfTSIBbST+KsFSzztDh+Ahcjnm1Tte/+sy/4lTF/sae5g== 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 Tue, Apr 29, 2025 at 05:45:53PM +0200, David Hildenbrand wrote: > On 29.04.25 16:52, David Hildenbrand wrote: > > On 29.04.25 16:45, Petr Vaněk wrote: > >> On Tue, Apr 29, 2025 at 04:29:30PM +0200, David Hildenbrand wrote: > >>> On 29.04.25 16:22, Petr Vaněk wrote: > >>>> folio_pte_batch() could overcount the number of contiguous PTEs when > >>>> pte_advance_pfn() returns a zero-valued PTE and the following PTE in > >>>> memory also happens to be zero. The loop doesn't break in such a case > >>>> because pte_same() returns true, and the batch size is advanced by one > >>>> more than it should be. > >>>> > >>>> To fix this, bail out early if a non-present PTE is encountered, > >>>> preventing the invalid comparison. > >>>> > >>>> This issue started to appear after commit 10ebac4f95e7 ("mm/memory: > >>>> optimize unmap/zap with PTE-mapped THP") and was discovered via git > >>>> bisect. > >>>> > >>>> Fixes: 10ebac4f95e7 ("mm/memory: optimize unmap/zap with PTE-mapped THP") > >>>> Cc: stable@vger.kernel.org > >>>> Signed-off-by: Petr Vaněk > >>>> --- > >>>> mm/internal.h | 2 ++ > >>>> 1 file changed, 2 insertions(+) > >>>> > >>>> diff --git a/mm/internal.h b/mm/internal.h > >>>> index e9695baa5922..c181fe2bac9d 100644 > >>>> --- a/mm/internal.h > >>>> +++ b/mm/internal.h > >>>> @@ -279,6 +279,8 @@ static inline int folio_pte_batch(struct folio *folio, unsigned long addr, > >>>> dirty = !!pte_dirty(pte); > >>>> pte = __pte_batch_clear_ignored(pte, flags); > >>>> > >>>> + if (!pte_present(pte)) > >>>> + break; > >>>> if (!pte_same(pte, expected_pte)) > >>>> break; > >>> > >>> How could pte_same() suddenly match on a present and non-present PTE. > >> > >> In the problematic case pte.pte == 0 and expected_pte.pte == 0 as well. > >> pte_same() returns a.pte == b.pte -> 0 == 0. Both are non-present PTEs. > > > > Observe that folio_pte_batch() was called *with a present pte*. > > > > do_zap_pte_range() > > if (pte_present(ptent)) > > zap_present_ptes() > > folio_pte_batch() > > > > How can we end up with an expected_pte that is !present, if it is based > > on the provided pte that *is present* and we only used pte_advance_pfn() > > to advance the pfn? > > I've been staring at the code for too long and don't see the issue. > > We even have > > VM_WARN_ON_FOLIO(!pte_present(pte), folio); > > So the initial pteval we got is present. > > I don't see how > > nr = pte_batch_hint(start_ptep, pte); > expected_pte = __pte_batch_clear_ignored(pte_advance_pfn(pte, nr), flags); > > would suddenly result in !pte_present(expected_pte). The issue is not happening in __pte_batch_clear_ignored but later in following line: expected_pte = pte_advance_pfn(expected_pte, nr); The issue seems to be in __pte function which converts PTE value to pte_t in pte_advance_pfn, because warnings disappears when I change the line to expected_pte = (pte_t){ .pte = pte_val(expected_pte) + (nr << PFN_PTE_SHIFT) }; The kernel probably uses __pte function from arch/x86/include/asm/paravirt.h because it is configured with CONFIG_PARAVIRT=y: static inline pte_t __pte(pteval_t val) { return (pte_t) { PVOP_ALT_CALLEE1(pteval_t, mmu.make_pte, val, "mov %%rdi, %%rax", ALT_NOT_XEN) }; } I guess it might cause this weird magic, but I need more time to understand what it does :) > The really weird thing is that this has only been seen on XEN. > > But even on XEN, a present pte should not suddenly get !present -- we're not > re-reading from ptep :/ > > -- > Cheers, > > David / dhildenb >