From patchwork Tue Apr 25 12:44:53 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolin Wang X-Patchwork-Id: 13223265 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 5F437C6FD18 for ; Tue, 25 Apr 2023 12:45:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC5B36B0071; Tue, 25 Apr 2023 08:45:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D75146B0074; Tue, 25 Apr 2023 08:45:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C63BE6B0075; Tue, 25 Apr 2023 08:45:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B2CB66B0071 for ; Tue, 25 Apr 2023 08:45:15 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 56701C014D for ; Tue, 25 Apr 2023 12:45:15 +0000 (UTC) X-FDA: 80719883790.12.57CBEEC Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) by imf05.hostedemail.com (Postfix) with ESMTP id 1508010000A for ; Tue, 25 Apr 2023 12:45:11 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf05.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682426713; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uezBm8gq6SNvgfo7IMNvOILdxqJER0Qo5EFJghYxVr0=; b=tvwyg1n2oT2YWX5q6IxQmTwg4Q4yfOURduYUpefoYwLRgMwjbF0HgYC0UKU7o70W3b1d/Z OzeGn8wA1+ePCe4jBopAkLfLajZvjSW6DRtnmJFtQweZS2qLdXqUtbESIJumHk2v93Z2ML mgxZVSabtgSpofrVdNPF0nDr24iagJo= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=alibaba.com; spf=pass (imf05.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682426713; a=rsa-sha256; cv=none; b=Kkt8sy7zgp7cssBy9R6+ZBzebNveJWiVglzA562CXLK2kAuD39ciYQlhCe+801XaP2nNkf xH0MIpnZPv0yeE0CVfZLL4glyNtcYCCe8WtdVN2XA0AiFQ+E38aBdUUpDNVKmd5ELYo5v+ O1IExTdgbt9cW1ftUfF+LCLjSWamWsM= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R121e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018045170;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0Vh-TY-f_1682426706; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0Vh-TY-f_1682426706) by smtp.aliyun-inc.com; Tue, 25 Apr 2023 20:45:07 +0800 From: Baolin Wang To: akpm@linux-foundation.org Cc: rppt@kernel.org, ying.huang@intel.com, mgorman@techsingularity.net, vbabka@suse.cz, mhocko@suse.com, david@redhat.com, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH v4] mm/page_alloc: add some comments to explain the possible hole in __pageblock_pfn_to_page() Date: Tue, 25 Apr 2023 20:44:53 +0800 Message-Id: <5c26368865e79c743a453dea48d30670b19d2e4f.1682425534.git.baolin.wang@linux.alibaba.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <98fa0a22-77d1-cdb3-1ce2-48a00c3ed5a9@linux.alibaba.com> References: <98fa0a22-77d1-cdb3-1ce2-48a00c3ed5a9@linux.alibaba.com> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 1508010000A X-Stat-Signature: rjbhxrnowkfa7aq3793usnsqubasa8aq X-HE-Tag: 1682426711-737086 X-HE-Meta: U2FsdGVkX1+VmjmiwJuLR1Kc3P+UASh37+1hym6v4T/odk+LcAf2tYPo85Tupvvm7IXS4xb2LoekgJsVycA6CrZIEKyD+gP8f7k9OKkIxm5HAg8vtmvuybHMMfLhOwibsG9WSan/gQDvn6qoY7+ir+UoNQnOY5g5/loB+bpUMQjRiwVMbhl8ohmYFDwKtWbp30jcieDA3Dhmc09zTCal7tB8zGqXCdSmjgO2/ciPF6k5vTZUw2raOuGZe8pv821CjxEZkHCDGWfPHRE6vFp8BpoTIo780w1RyWBx/AwOVcQQKG4trQ7MpQHFJu+l25KmUR4jP6Sw9nyL7qLch06CByOxO2VVTXtq4D2Brc+UP/ScCXWbCmn+mclY2XA/E8wEvFykGqOZyUwe4rW4kih0HYOudZQ2Y0kpzQ+OBdKWDt9X+hPHO3LIeW3lITuapr8IQK+r/Sl7a+bxUIqda3rgbxNmenjKwKazgfEwRKDQgw2lUg24gYGVNZXuhFy6Ny1DfBxponqbrAdxNTlPMjgOPqkPTs6HtnIjlH/b/Y6/+47tYGzx4gg3HjxmsKpphj2H+IYc8mJn0BCpJxC11ck4TU7LwPhNOm9NziywwH77O0g1BJIJ7urWL7FZt5IFnM7oNKjGwy+5b9+vWy0pJW/QsXxW6MSm4iU/Wa8YhSpxZmm90kf2hqHezDq3E0sONAWy+9IXb5+N7voz70hoh0THLjvl3C/PPdQyPI7JzU6dTHvo7JYwDgLlrs/ww516IrSdcgax2QfsJYVDlsgFbp+STg5LkSuYt7ZS2gcw+WHe1JH72UEES1F2UbwU6iHiRndk/iJXEQXcGVQIA7QQZ1QhvKVa55iUmVNAxLyTWz6yzMrrWH5ZQ1amuAWLqO5ZinlmVof1MVOsFs93qyBCE0LcwHRLe+H+3zs+i1E6ng5NNQinv0BtxFIEB5kn9FCKYGnxpeu6sBBWmT4KgGlCW4V V21QfJkp jhhoaF6EzTnY6cBSI3+AGfOS7+6gDP5DImXDc2v3iKixYXLBLRx49Jm0ercAl21xtDKamagd4Ugq4kZS1ZsVkzQwY2uWbB3GqMp3FPF1kG9mgaCEcJ3PjVkCW4TnsJU4k4tJWwD5yLyxU1zZBDNL77+REJeD6bX9kMjPfZFVbM96Gu/l+ZUi6JOu7Cx+fiZyXpKFukJvIldC6vnrqS9cKre1d3p4Kazi4coxM75EBl6EbZsQgxt5iHy8b9eadMkcf3ziMW9/NFVf/wBJfjE00jKN3s+btpTmgoaWlg3WQWqAVkw+9xXRHe0igegcqxOzc0sTw 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: Now the __pageblock_pfn_to_page() is used by set_zone_contiguous(), which checks whether the given zone contains holes, and uses pfn_to_online_page() to validate if the start pfn is online and valid, as well as using pfn_valid() to validate the end pfn. However, the __pageblock_pfn_to_page() function may return non-NULL even if the end pfn of a pageblock is in a memory hole in some situations. For example, if the pageblock order is MAX_ORDER, which will fall into 2 sub-sections, and the end pfn of the pageblock may be hole even though the start pfn is online and valid. See below memory layout as an example and suppose the pageblock order is MAX_ORDER. [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000040000000-0x00000000ffffffff] [ 0.000000] DMA32 empty [ 0.000000] Normal [mem 0x0000000100000000-0x0000001fa7ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000040000000-0x0000001fa3c7ffff] [ 0.000000] node 0: [mem 0x0000001fa3c80000-0x0000001fa3ffffff] [ 0.000000] node 0: [mem 0x0000001fa4000000-0x0000001fa402ffff] [ 0.000000] node 0: [mem 0x0000001fa4030000-0x0000001fa40effff] [ 0.000000] node 0: [mem 0x0000001fa40f0000-0x0000001fa73cffff] [ 0.000000] node 0: [mem 0x0000001fa73d0000-0x0000001fa745ffff] [ 0.000000] node 0: [mem 0x0000001fa7460000-0x0000001fa746ffff] [ 0.000000] node 0: [mem 0x0000001fa7470000-0x0000001fa758ffff] [ 0.000000] node 0: [mem 0x0000001fa7590000-0x0000001fa7dfffff] Focus on the last memory range, and there is a hole for the range [mem 0x0000001fa7590000-0x0000001fa7dfffff]. That means the last pageblock will contain the range from 0x1fa7c00000 to 0x1fa7ffffff, since the pageblock must be 4M aligned. And in this pageblock, these pfns will fall into 2 sub-section (the sub-section size is 2M aligned). So, the 1st sub-section (indicates pfn range: 0x1fa7c00000 - 0x1fa7dfffff ) in this pageblock is valid by calling subsection_map_init() in free_area_init(), but the 2nd sub-section (indicates pfn range: 0x1fa7e00000 - 0x1fa7ffffff ) in this pageblock is not valid. This did not break anything until now, but the zone continuous is fragile in this possible scenario. So as previous discussion[1], it is better to add some comments to explain this possible issue in case there are some future pfn walkers that rely on this. [1] https://lore.kernel.org/all/87r0sdsmr6.fsf@yhuang6-desk2.ccr.corp.intel.com/ Signed-off-by: Baolin Wang Acked-by: Michal Hocko Reviewed-by: "Huang, Ying" --- Changes from v3: - Update the comments to make it clear. - Add acked tag from Michal. Changes from v2: - Update the commit log and comments per Michal, thanks. Changes from v1: - Update the comments per Ying and Mike, thanks. --- mm/page_alloc.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6457b64fe562..af9c995d3c1e 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1502,6 +1502,15 @@ void __free_pages_core(struct page *page, unsigned int order) * interleaving within a single pageblock. It is therefore sufficient to check * the first and last page of a pageblock and avoid checking each individual * page in a pageblock. + * + * Note: the function may return non-NULL struct page even for a page block + * which contains a memory hole (i.e. there is no physical memory for a subset + * of the pfn range). For example, if the pageblock order is MAX_ORDER, which + * will fall into 2 sub-sections, and the end pfn of the pageblock may be hole + * even though the start pfn is online and valid. This should be safe most of + * the time because struct pages are still initialized via init_unavailable_range() + * and pfn walkers shouldn't touch any physical memory range for which they do + * not recognize any specific metadata in struct pages. */ struct page *__pageblock_pfn_to_page(unsigned long start_pfn, unsigned long end_pfn, struct zone *zone)