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 A87FAC71130 for ; Tue, 8 Jul 2025 02:53:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4C8766B02A7; Mon, 7 Jul 2025 22:53:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 479636B02A9; Mon, 7 Jul 2025 22:53:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 341316B02AB; Mon, 7 Jul 2025 22:53:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1A7AD6B02A7 for ; Mon, 7 Jul 2025 22:53:11 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B778416043E for ; Tue, 8 Jul 2025 02:53:10 +0000 (UTC) X-FDA: 83639575740.21.624DBE4 Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf02.hostedemail.com (Postfix) with ESMTP id E694A80006 for ; Tue, 8 Jul 2025 02:53:08 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="egOwzI1/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of hughd@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751943189; a=rsa-sha256; cv=none; b=FqlrdfM6ewrP0K9prTVPcXh4L745DxvVJrSS2CbdL0agowqxgnd87gigN8rShfwQGK/MY5 iKnQqfjnbO85QgDdTKO2cDRIG+3aVxtNDxBG29XWnbJWWJ7M5FgRn8c8w9hJCgg2782GdD bq6o3LwvryXD+EYKbp9/JwIvyyBpQhw= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="egOwzI1/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of hughd@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=hughd@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751943189; 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=/zGCQGxHrSRe/NxvAWIAsgtbup/awoRMVdcTUBJfyTs=; b=vkZoGoiAQbWD4FFh/O4g7rOOXAcHvlYKMS0nO6ARhF4o/fUY377rbOnEjKppKpOXTgIw/n gcJfFfs+reKNiTGUJWkoGYnah3U1fn4rnTgDbhhk92Mqu6DzbYyj3+GpzTj1TesRG54K4e 8SuJfJt6Q4SNsyEyyOtPtZVkKwDLorU= Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-717a2ef8943so902177b3.1 for ; Mon, 07 Jul 2025 19:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1751943188; x=1752547988; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=/zGCQGxHrSRe/NxvAWIAsgtbup/awoRMVdcTUBJfyTs=; b=egOwzI1/bGbxhYJ/KG/nZWP5kSv35x6CZfytcDyacnxoAL/naDEM/3MRLZQRBlL32I REkXghvHg5mzFWZUREH7bmiKvapl7WeMQsRE7iZeWRgqf7AwSdIs4Jhk2Hu/vVonQpRC YXdx/V7PuuXsEQ73079YICoSsKJPA1TZyWR1hgJ1J9YDgDqaEq90rRdnZiVWXOkC4CIU R0YwSgSGX4xwgUsOEIqUNmV5dScqGl1yf2BZEzYWpOLCQxrshIJawlZ3l3ZyVkJ1ckM9 FLPsW3PtAvJsacNqwIj2s6YEtzT2evna58arxe0glBSNjLjYMmkq7tzLAreEpkh15tV3 9j+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751943188; x=1752547988; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/zGCQGxHrSRe/NxvAWIAsgtbup/awoRMVdcTUBJfyTs=; b=ixOp2kK9E9oC/NMNu3SZcxJSDPQuN+7vmFWr0y3C1ZxZ4ZxTDlRge1ej5gN8DyeGoT bSeE4cfobAuuTYanekPg7UbGM7CHQfomElShY+U2XpGLZmGR0WwWQMchhzzXfOumDlyA mdeuxPIXDEaRg/BYLhLzmO7+4BkOEsCt4qWiK9r68E/tQ9ckXIXnKFG5C3ROvH57hTQ5 qEjU4HwidyJXZ9dNeNcBjuSI2yclBRHnj8rruJpvw0w1ZFAWRGgv3rtvUpVERD7dSfZm A62HEJkDuv4KIZfLaos6qkWDEzJ2B1dVLldRWV+ir3k0aNrz5tIsPt3Uc5qx2IxKI3qT u/MQ== X-Forwarded-Encrypted: i=1; AJvYcCWcYUIeN0FALrtW+Q5DuG+RVYr6N0X+XUaM5C6matPYtDABWZapvvlqoa8mYwMzMBYsRtUx3AX5Ow==@kvack.org X-Gm-Message-State: AOJu0YxnRVW9L0fuWhcoQFPaehD0g6lzW1KEkDiVsEFxFP1bRMJ8Klmk CK2YP6lJnIDIbYFa8A3BCWsK6N7/gA+cGKawiLoacfO4mNe2w7YQLCOLQC2bewxLkw== X-Gm-Gg: ASbGnctKoR2X+OzeOuOnwZtyaVvJLnqU9rfoBoPOqIzNEMKGk2bpinx7g3kTquWcBP6 S6gzgxIn7lomhCBOl2fk+dclpNybeEenRo65FRynKzem6ljHLO/gmnWKCU2qE/lTJlCEXg3ve+m LZaqEys7wECLxX0NtsIVCXkMajkdfYyScQXjzwj3cQUyNQ8F3aMuZ6FXVzpHGb2Nu/uBq1/8w+Q MieSun98Wfn88i82CQSS49cl6rEYpZQJPS3b8jcTHk2XGHJd/UfSTvkRoabt8nna+X2y3FJKmiO AWJzBTRn9okRpuVVZ9ctPdGgneGZSVJd6zZallok8DKyEtVH90I6/7sM9qoZZ6Dy2e9+H0w13nH QuVXHRR2sny/BOee6IdRCdZJAznQZT6ukBMEX73h9RQS7cPc= X-Google-Smtp-Source: AGHT+IFGk1zw6u42yZgVl3xmkGAoYOyMoRKxLmKRqsd/hjEURFvgk/4mOy+h8KG+4313YBELzU59vA== X-Received: by 2002:a05:690c:62c6:b0:716:69e0:bb85 with SMTP id 00721157ae682-717a036f27fmr14923907b3.18.1751943187668; Mon, 07 Jul 2025 19:53:07 -0700 (PDT) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 00721157ae682-71665ae2c29sm19151417b3.78.2025.07.07.19.53.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Jul 2025 19:53:06 -0700 (PDT) Date: Mon, 7 Jul 2025 19:52:51 -0700 (PDT) From: Hugh Dickins To: David Hildenbrand cc: Hugh Dickins , Lance Yang , Oscar Salvador , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, nvdimm@lists.linux.dev, Andrew Morton , Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , Dan Williams , Alistair Popple , Matthew Wilcox , Jan Kara , Alexander Viro , Christian Brauner , Zi Yan , Baolin Wang , Lorenzo Stoakes , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Jann Horn , Pedro Falcato , Lance Yang Subject: Re: [PATCH RFC 01/14] mm/memory: drop highest_memmap_pfn sanity check in vm_normal_page() In-Reply-To: <36dd6b12-f683-48a2-8b9c-c8cd0949dfdc@redhat.com> Message-ID: <0b1cb496-4e50-252e-5bcf-74a89a78a8c0@google.com> References: <20250617154345.2494405-1-david@redhat.com> <20250617154345.2494405-2-david@redhat.com> <5e5e8d79-61b1-465d-ab5a-4fa82d401215@redhat.com> <36dd6b12-f683-48a2-8b9c-c8cd0949dfdc@redhat.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1463770367-475110467-1751943186=:6773" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E694A80006 X-Stat-Signature: sfgygf3uuc698ojtj49aufg1wjbgxtw9 X-Rspam-User: X-HE-Tag: 1751943188-162438 X-HE-Meta: U2FsdGVkX184EBwDSX0jEzrStrjFY2DdoACtFJgBZynYglhX/aUpT4GtsmUFQLr84Knt5sXyMjufQJelJT75ABcjenkISP4HQNl5MIOY/Mh/ICJWf6QkmEYv/eUpMLiaMz6EPZSqNGU/NcONI5FJgdsXbrcVG/iESDPe0ZojeEPfZ5kxry7EUCCZtE4PaPY6qBohnEOCETviNFNMS5hrpvJ6qqvkrvm1CdMQWWrpNkHyw2obo5jN0ClcWgy0umuXIvkQQnmw6cKRngamuCjCQHpyrflQjPygrj28HGBpg2LseguTMRhBPHi2fEM9jCfhckyPQUyw8h9p48xpA6XqkIhtynKpfHbN27258OmOPnggg7Kgwf04Kid1mbn/bVHz6QESAP4XR4/U9ILtMeX50AVHtWtO3gcFfypHU+wj+6hvmtFbHX/OA8HvnxNao71Pchtn7Z0JIpNWVnTBReStuKbDsJBWHsoRBU8NJOAaC/vExb3j3wgAni23OU2txBo2jZU3riYbJoqITcao6uxypxLeewkbcbqJYjj+aNsZOAt0I37l9F9aQuEq94eHrkI16LBILWQc2NbnsZKUDaTUV1BKb7yji9Es7Td2ZmyYT61LFpyYrLzh2suZNgwoLvX+NM+EyPaOrw+DGsfuDepWoI9eqSAtw7JuocY9NpdlaW4V0SF/PN1PNuS4EFJL9isV+6XyyG1uqPBsOO1CsZ3nb+NIh1DaUMy36s0IUKebxj8BafhnSSVK0OLQidwqrdDmHqbKD/chTyFUBUNIA2wy2oDGOWwArjSkA3ef//3jYg1w1ClX2h3VXIKfNp8C7OVxOYofk44PSlilCS3QSP+3Zyru6G08mzFCuYsCI0LY7IGdSyKoFyOJp0EjqIv3hxE48Biqj5NE1HBOZ9ZV2XCOb63dXnD6TXAFWyOwRI79e2/XWRmFPe8zhp3qsmX74CWe4zberVxTofGVSrzPdmW 29qp0cqx BM8sCpnL1eJ+gEZoG6lK6Ic+j2vnbwQtS7QoQxLHYakBHpjpyTX2dEortLYl20sYDbL4YPGAssF1NU2+xprhqdrHsyQllpxyNR69CsW1oujFOUYmWiFN35x/wJfRCaLK4rqQ0GPgPtwAq+GqGWx5w2TiEvotG3C1F6BzzHNYbnwsiIX9AsaUUopC806nkqzEBqnY50YcDwVBykusorHh28zVqLwZOvKnpwV04CzSYJysd1J3SRf6LpBcYXa/23bSzg6gpWXiM0lcGTeFQYT7PM0Dgt8zZ4c8nnTJ0cFHDS1HH4ZIPLfPyH/E0UKJMC+1E83PAAnBPrO5CxMogqL9IcddxATJdBbYUlOgHEEj4rZeINhWQyx85LBNqAuiahj8zA1fa5WCFFQ3KYtfhEcm9jY6/wO5GF9ORISJ3pHjXtnY3rxaBJ6PXBTCax39Z6Decv9zXYtuAlM85mqhwgVtJrByz/Av0hrU194BtckTxyoZQu9CDBaXidjNCNTBdJhyigm+B+LXlgu/wtdbuFoCV4ZljGVEB85ErHgWUFVTtbQj0Ww+VWv8R7HGzSZRCXqCZC2QkbjdhA6UfqrJfxH6KwFcwI4WtFN6x1RwB5XycQonyTY0= 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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463770367-475110467-1751943186=:6773 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 7 Jul 2025, David Hildenbrand wrote: > On 07.07.25 08:31, Hugh Dickins wrote: > > On Fri, 4 Jul 2025, David Hildenbrand wrote: > >> On 03.07.25 16:44, Lance Yang wrote: > >>> On 2025/7/3 20:39, David Hildenbrand wrote: > >>>> On 03.07.25 14:34, Lance Yang wrote: > >>>>> On Mon, Jun 23, 2025 at 10:04=E2=80=AFPM David Hildenbrand > >>>>> wrote: > >>>>>> > >>>>>> On 20.06.25 14:50, Oscar Salvador wrote: > >>>>>>> On Tue, Jun 17, 2025 at 05:43:32PM +0200, David Hildenbrand wrote= : > >>>>>>>> In 2009, we converted a VM_BUG_ON(!pfn_valid(pfn)) to the curren= t > >>>>>>>> highest_memmap_pfn sanity check in commit 22b31eec63e5 ("badpage= : > >>>>>>>> vm_normal_page use print_bad_pte"), because highest_memmap_pfn w= as > >>>>>>>> readily available. highest_memmap_pfn was introduced by that commit for this purpose. > >>>>>>>> > >>>>>>>> Nowadays, this is the last remaining highest_memmap_pfn user, an= d > >>>>>>>> this > >>>>>>>> sanity check is not really triggering ... frequently. > >>>>>>>> > >>>>>>>> Let's convert it to VM_WARN_ON_ONCE(!pfn_valid(pfn)), so we can > >>>>>>>> simplify and get rid of highest_memmap_pfn. Checking for > >>>>>>>> pfn_to_online_page() might be even better, but it would not hand= le > >>>>>>>> ZONE_DEVICE properly. > >>>>>>>> > >>>>>>>> Do the same in vm_normal_page_pmd(), where we don't even report = a > >>>>>>>> problem at all ... > >>>>>>>> > >>>>>>>> What might be better in the future is having a runtime option li= ke > >>>>>>>> page-table-check to enable such checks dynamically on-demand. > >>>>>>>> Something > >>>>>>>> for the future. > >>>>>>>> > >>>>>>>> Signed-off-by: David Hildenbrand > >=20 > > The author of 22b31eec63e5 thinks this is not at all an improvement. > > Of course the condition is not triggering frequently, of course it > > should not happen: but it does happen, and it still seems worthwhile > > to catch it in production with a "Bad page map" than to let it run on > > to whatever kind of crash it hits instead. >=20 > Well, obviously I don't agree and was waiting for having this discussion = :) >=20 > We catch corruption in a handful of PTE bits, and that's about it. You ne= ither > detect corruption of flags nor of PFN bits that result in another valid P= FN. Of course it's limited in what it can catch (and won't even get called if the present bit was not set - a more complete patch might unify with those various "Bad swap" messages). Of course. But it's still useful for stopping pfn_to_page() veering off the end of the memmap[] (in some configs= ). And it's still useful for printing out a series of "Bad page map" messages when the page table is corrupted: from which a picture can sometimes be built up (isolated instance may just be a bitflip; series of them can sometimes show e.g. ascii text, occasionally helpful for debugging). >=20 > Corruption of the "special" bit might be fun. >=20 > When I was able to trigger this during development once, the whole machin= e > went down shortly after -- mostly because of use-after-free of something = that > is now a page table, which is just bad for both users of such a page! >=20 > E.g., quit that process and we will happily clear the PTE, corrupting dat= a of > the other user. Fun. >=20 > I'm sure I could find a way to unify the code while printing some compara= ble > message, but this check as it stands is just not worth it IMHO: trying to > handle something gracefully that shouldn't happen, when really we cannot > handle it gracefully. So, you have experience of a time when it didn't help you. Okay. And we have had experience of other times when it has helped, if only a little. Like with other "Bad page"s: sometimes helpful, often not; but tending to build up a big picture from repeated occurrences. We continue to disagree. I can't argue more than append the 2.6.29 commit message, which seems to me as valid now as it was then. From=2022b31eec63e5f2e219a3ee15f456897272bc73e8 Mon Sep 17 00:00:00 2001 From: Hugh Dickins Date: Tue, 6 Jan 2009 14:40:09 -0800 Subject: [PATCH] badpage: vm_normal_page use print_bad_pte print_bad_pte() is so far being called only when zap_pte_range() finds negative page_mapcount, or there's a fault on a pte_file where it does not belong. That's weak coverage when we suspect pagetable corruption. Originally, it was called when vm_normal_page() found an invalid pfn: but pfn_valid is expensive on some architectures and configurations, so 2.6.24 put that under CONFIG_DEBUG_VM (which doesn't help in the field), then 2.6.26 replaced it by a VM_BUG_ON (likewise). Reinstate the print_bad_pte() in vm_normal_page(), but use a cheaper test than pfn_valid(): memmap_init_zone() (used in bootup and hotplug) keep a __read_mostly note of the highest_memmap_pfn, vm_normal_page() then check pfn against that. We could call this pfn_plausible() or pfn_sane(), but I doubt we'll need it elsewhere: of course it's not reliable, but gives much stronger pagetable validation on many boxes. Also use print_bad_pte() when the pte_special bit is found outside a VM_PFNMAP or VM_MIXEDMAP area, instead of VM_BUG_ON. Signed-off-by: Hugh Dickins Cc: Nick Piggin Cc: Christoph Lameter Cc: Mel Gorman Cc: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds ---1463770367-475110467-1751943186=:6773--