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 B1B89C77B7C for ; Thu, 3 Jul 2025 14:44:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 48F9594000A; Thu, 3 Jul 2025 10:44:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 440E3940007; Thu, 3 Jul 2025 10:44:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 32F4694000A; Thu, 3 Jul 2025 10:44:59 -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 219E6940007 for ; Thu, 3 Jul 2025 10:44:59 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CEA4A80275 for ; Thu, 3 Jul 2025 14:44:58 +0000 (UTC) X-FDA: 83623225476.05.8DF4B66 Received: from out-189.mta1.migadu.com (out-189.mta1.migadu.com [95.215.58.189]) by imf09.hostedemail.com (Postfix) with ESMTP id C5CF214000A for ; Thu, 3 Jul 2025 14:44:56 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="xw0Nq/aB"; spf=pass (imf09.hostedemail.com: domain of lance.yang@linux.dev designates 95.215.58.189 as permitted sender) smtp.mailfrom=lance.yang@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751553897; 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=JOIrRfIeyTH2apsnsGitpg+mindX/IyZqQlNCkKTr4I=; b=oPKBxzuv1RbMnUxFfkymcYuUR9mSBc8fLEPztlPqeLt5k5Acoxy1WhApt6KjeejPtJc8vO yLDO9FbIxokMXknX7mSLV1BWLjLRXyrouP0m0/VQJHyXftngHjncDp+MTCmeCSNco+Qbl5 FNe5uHgwrwX2pwsplKg52ahdieY+En4= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="xw0Nq/aB"; spf=pass (imf09.hostedemail.com: domain of lance.yang@linux.dev designates 95.215.58.189 as permitted sender) smtp.mailfrom=lance.yang@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751553897; a=rsa-sha256; cv=none; b=3tor27DuyQvT2uhFR6Drjme3MmHLEKvVNUNQN2FWAOawGPFyGzgpDSeRb4ozJiTljcYGLB Yu1s5+K/KXc+U+J+qnWMaCWth7BC2/+7j9g36F626sZZDDU9dZi0j/rqpgpsJ8tg5JGw9Q vPUWA/EaDO2XzzJ/rfHsLAGnSg1J3pE= Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1751553894; h=from:from: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; bh=JOIrRfIeyTH2apsnsGitpg+mindX/IyZqQlNCkKTr4I=; b=xw0Nq/aBHVz2IZHt44g+yDNXMx0Jed8Ecs/I7Q8XpWowwI0KhrCtu7tM8hiuQMEO4xFxZq Pucfwly1yrq2L5+Uh3Y/1m/oyNxJlaLfYA+rF+qU27u4jKqGLYBBXKLdsVmYvbjzI4qgdE 5jQ8Y1ofO5WJu7Xdc9pFpUFAAWtApgY= Date: Thu, 3 Jul 2025 22:44:44 +0800 MIME-Version: 1.0 Subject: Re: [PATCH RFC 01/14] mm/memory: drop highest_memmap_pfn sanity check in vm_normal_page() Content-Language: en-US To: David Hildenbrand Cc: 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 References: <20250617154345.2494405-1-david@redhat.com> <20250617154345.2494405-2-david@redhat.com> <5e5e8d79-61b1-465d-ab5a-4fa82d401215@redhat.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <5e5e8d79-61b1-465d-ab5a-4fa82d401215@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Stat-Signature: y8mcmjgp7wfhxkk8ucqarmn16bo3ydep X-Rspamd-Queue-Id: C5CF214000A X-Rspamd-Server: rspam11 X-Rspam-User: X-HE-Tag: 1751553896-56496 X-HE-Meta: U2FsdGVkX1+j+1tk6z6dfMJc6HMDky6oIITSDeiWPRJY7nsS4zEfdcZxmOGbffrsTLxaHqzGV2peYi4nSLWXMi1b1EpRkN5hEDwh6lEfWrMCV0j4juPGhscN66ENrf7L1gCxRd/ljRCmntAmWU5l+SRDYsTKB9PCdJV5ZfBQjjghTNefV7o9wrUxfiB0kVFqpw9FUMD70uw9JnVXqaxYXyLkJgOnXQr5C8Zw2qFHjRyP1hgJqnSIuHz1454BWyjj7LhgU0n5O1uPRF5ePGsUSXLVAthfQjiGhqFen3eggXlq13WPCJwD/DyoSJX6Hln6hd9yZKfvFDjTV+klAYBax3QiZkX6t6pNegA8Oml+apEv4VB0M9XAewsaCP6nLhNm4BqJYnLgXfy1m6hceG89vyR4rJGMyqDTWU+xkWNE1rChqCI5NLw+Sd7UC+2WXIkxdhoYnNaaihm9KV+/CHzuPVMIdxf/MXz06FSJa2zh0nt3YljKb0iHAm68ja9oBiaRifhXZYnxlIUjcHiJ7Bdzr3tbJkeIWBuMOjsKkLwkwj5aYsjjL6Ud+XBdBnLTkn3woq5+khEX7l/r5/SCICZSE/ZaGez/9gQgrY1qg2QS7pH6/qhsJ43NHqpDDDpBbJ+jeZJsJEj7uYM8mR+YCkHtYFARGqDlar/PGta3Rsfgf6NH/7SD9oLDXOy0tMxmM3KYSzIzgjIrir4gP8V3nJkPyUuX1+UurGl0o2s1snYY7QjEyxwl52UwRHuuj8UUPNL3j2+6/FR4cekJJhyC/10fyNqEBBPCM7CdFPuIv4DCIt16t6wZm67NaMU7RBPOJn0o+AU5bP2x6P3xYt6qMW3ANNhzgjxaC4nl+MlQ0MGg+1XFBG4A217lXqELrP8oCDRjS9OoQoUmdTYP4Vrq5vPtysHVDB7t3rbrJoeEzRNZ2O/+eStfGZXsmh0vUojQHxuacBKmzzhC2+1ga5/623r iEd1IdD6 /sVI7opG2HBjvfLykwX4Jb0T5D9/3S+0k6UQzIJjZOGzUIdUHpKAuVt1yOgtX/Brn/sK7BmRYhbZO4vBWLtBqVXcERhz2OyKFe04rGpVxq9b2p5cL2m0E5gTUuoI9vTwReF/UQHfvr2hXyP4obPR9S+RbxJ/KCfppH1kOfZNdjbj0Kl54aI9eS0l2TM1pjG9/5AsNVwjnisnS5oqzxvGv8mvKhZrEzTmYAmT6CBGGMWxFuTea9gEDDedJ1kkwhIRlnHYSxA3MLD0sEnf0fxxk1RGohQ== 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 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 PM 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 current >>>>> highest_memmap_pfn sanity check in commit 22b31eec63e5 ("badpage: >>>>> vm_normal_page use print_bad_pte"), because highest_memmap_pfn was >>>>> readily available. >>>>> >>>>> Nowadays, this is the last remaining highest_memmap_pfn user, and 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 handle >>>>> 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 like >>>>> page-table-check to enable such checks dynamically on-demand. >>>>> Something >>>>> for the future. >>>>> >>>>> Signed-off-by: David Hildenbrand >>>> >>> >>> Hi Oscar, >>> >>>> I'm confused, I'm missing something here. >>>> Before this change we would return NULL if e.g: pfn > >>>> highest_memmap_pfn, but >>>> now we just print the warning and call pfn_to_page() anyway. >>>> AFAIK, pfn_to_page() doesn't return NULL? >>> >>> You're missing that vm_normal_page_pmd() was created as a copy from >>> vm_normal_page() [history of the sanity check above], but as we don't >>> have (and shouldn't have ...) print_bad_pmd(), we made the code look >>> like this would be something that can just happen. >>> >>> " >>> Do the same in vm_normal_page_pmd(), where we don't even report a >>> problem at all ... >>> " >>> >>> So we made something that should never happen a runtime sanity check >>> without ever reporting a problem ... >> >> IIUC, the reasoning is that because this case should never happen, we can >> change the behavior from returning NULL to a "warn and continue" model? > > Well, yes. Point is, that check should have never been copy-pasted that > way, while dropping the actual warning :) Ah, I see your point now. Thanks for clarifying! > > It's a sanity check for something that should never happen, turned into > something that looks like it must be handled and would be valid to > encounter. Yeah. Makes sense to me ;)