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 5943CC6FD18 for ; Sat, 22 Apr 2023 10:15:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D26FA6B0074; Sat, 22 Apr 2023 06:15:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB0136B0075; Sat, 22 Apr 2023 06:15:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B511A6B0078; Sat, 22 Apr 2023 06:15:36 -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 A19006B0074 for ; Sat, 22 Apr 2023 06:15:36 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7273014013F for ; Sat, 22 Apr 2023 10:15:36 +0000 (UTC) X-FDA: 80708620272.24.9FE5E42 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) by imf28.hostedemail.com (Postfix) with ESMTP id 64981C0004 for ; Sat, 22 Apr 2023 10:15:33 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682158534; 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=YcLa0KSM8wD3Sx5aB5eDsccrbn1dqKcpDuLQ6Mqt8Ks=; b=a3nCAgjp7gXDEjxDX+kVe+4z6NBuxFkkQn8lqqTbNEeU1MKs1sP1dbeKpbjSYibxEhCvzW NhxeOMmh8/r7cSGFeo4x0vkQrnvo2L95PoZOXpu2CMNW94+hFz2rdWybnEYi56QYT0pltD RwxDrUmGuVf+M9LNa69G54Ckl4vanpk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682158534; a=rsa-sha256; cv=none; b=t5dl7Aa1+bETh6Sg7roOzOQxJbBf9n1H3bZrsgOVjiII5i8kQJTrjkD8VLrQ8ygPO3eMXG BFey0CuzWA/tdzy/Id1H5XvKlnElOy5DszFtoBzGCOQHPaUgc9yaZo8fMuEj1uJANBNwP6 DrFq3DuHEYTaZNrHShXVBTviqFJ3mSo= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.119 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R691e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0VgfnVKn_1682158528; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0VgfnVKn_1682158528) by smtp.aliyun-inc.com; Sat, 22 Apr 2023 18:15:29 +0800 From: Baolin Wang To: akpm@linux-foundation.org Cc: 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 2/2] mm/page_alloc: add some comments to explain the possible hole in __pageblock_pfn_to_page() Date: Sat, 22 Apr 2023 18:15:18 +0800 Message-Id: <02defcbe9d7a797a2257e5f6a28ff7ea78e394e5.1682158312.git.baolin.wang@linux.alibaba.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 64981C0004 X-Rspamd-Server: rspam09 X-Stat-Signature: k9ruzdsaq6w118ssikuqyoy9ozyxi5ap X-HE-Tag: 1682158533-971259 X-HE-Meta: U2FsdGVkX18eD5moDNcIwGJcERMnrA+BG3lp8TKZ4eRNYSd04pRmnWMNo0p/hjleiOlinBTFItOyxgmR2odGh4T/wLzjN6t/TgrH+oZ8E0pD85iMUMveSIJXSVHaKL8SNxzTxJLLrs0uoMEhAqeN5YkNi9qk3trdrC9A1R7sHT4ZUFaZI/0HEcho9hKmNGdLpjJOgA36rGymb7ZB+ZGggLreG2z/Slj179l/LeZ5AbQJNYBGakrldpQE6gtCpswr1Qb0yiD4PgCsssg9KXBsIyigdAubffN5x8FCzvnXroDjW7LCb+z7vUaPuWoAewPwJET/KgILEup+lf+P9ItVzFgTN/PiBhR0cypzYihhLj3798LLBB4Hik4u97tj+oMY1OsaMvxxZDowuLJl3vYEDU68jvCw80KCvO7cQ4weZXE2TsUC1IvNBAaOwsLWrO+42CWjE7V41Pw9T6zyl8zs8dH4z0VUNoi+45IlY2j2sn3jNF2qejM+CHTACrzQa2GTPBGcD+rWjyX0rbABgBn6DWol7d36F7GD+K9zeiwKJZTYSCYaE7KXr2MavOu4Wn1max8omZ84Pbt8CS6ZO041GeUT8FMVfhvY/xbQ1v/HqOhOQ5y48pNDLsoz4ZHmURzHY0hF8xF/9M975l5nYRU4mLDB6XEQJq+2fzjMcV9m7cS28O4qsIcQzUYKMD9Rg8TxZ8OMierN/WHTibp6gMAFA/mGWbpRA0EHBnafd8Ez1Dqdlvy8xeezEA/yvmPV3wCMtyd9SlCYjcOK2LhjaPuHSdfm+Fm50xaN3vYN7pnSYGguvlNJx85wsxuYjW3Z19//+FCzU9MsmbFLHieIchd0miftoHRJLnxxxB1nTOHY4M460YVHoADoRRGNG0bCGf2rXqF2P3uaqvFcUJI+nI61iUVf/d+SrqZmbNNXhbRLcO7OHfqzw9671AQObD7pibVnLVRYAyR2Q5W5geGOzHM FSLKI87J 7o5PqAHQgAflLIGmrU1S4T/XfgJEvMcrrykpd5GGJsUFLRspXC2DgQd00TwY/nJ3u8y9rYovqCxKPUSOYn984gr50mD5yDUl0pcZ5fdltDvdCawBy+Ou01ilGpI0/Ho+aRGzimMC8kTcDLn+zhOxx5LL1SPNO3pBVED1gew758xq1UY2IkX9pQdGaLthKDXnBZh3Qo51Gv1H1gRVgX9KCEQeGfDY0TsXrT9ftl/uGzchofX/Piv282Jel9LrBQ8QTOdfd 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, though the start pfn of a pageblock is valid, it can not always guarantee the end pfn of the pageblock is also valid (may be holes) in some cases. For example, if the pageblock order is MAX_ORDER - 1, 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 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 --- mm/page_alloc.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6457b64fe562..dc4005b32ae0 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1502,6 +1502,14 @@ 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: if the start pfn of a pageblock is valid, but it can not always guarantee + * the end pfn of the pageblock is also valid (may be holes) in some cases. For + * example, if the pageblock order is MAX_ORDER - 1, 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 did not break anything until now, but be + * careful this possible issue when checking if the whole pfns are valid of a + * pageblock. */ struct page *__pageblock_pfn_to_page(unsigned long start_pfn, unsigned long end_pfn, struct zone *zone) -- 2.27.0