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 F3804C77B61 for ; Mon, 24 Apr 2023 09:54:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E50A6B0071; Mon, 24 Apr 2023 05:54:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 794B26B0074; Mon, 24 Apr 2023 05:54:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65C2D6B0075; Mon, 24 Apr 2023 05:54:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 52F426B0071 for ; Mon, 24 Apr 2023 05:54:12 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1D8A61402B0 for ; Mon, 24 Apr 2023 09:54:12 +0000 (UTC) X-FDA: 80715823944.12.23D9B22 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf08.hostedemail.com (Postfix) with ESMTP id 33CD8160007 for ; Mon, 24 Apr 2023 09:54:09 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=oqXh4VIQ; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682330050; 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=IbUIip9bYjgV7vUOobjAK4CkjYy7pzt27Q+UhD49leA=; b=eNgwA/2ufdLGVHR++/09T+qTGh8Dbb8TqorQd0P8xSphcJTIxXNzUeeQvqu7g42lX/zCyc 2ojSnP4+c7D/2/JQg21IZDMsU8HOA0dfHVUzT4Lt9ZV66p+FoC4KkWbDdMdCGTMRES9v9m JAbExosHSI9YB4fzXtg8cTHtKi2qeFs= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=oqXh4VIQ; spf=pass (imf08.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682330050; a=rsa-sha256; cv=none; b=2r7hMCT06W6YF3PlR4yJkKob4ptihF2mhXLQECa1PQwl7szNek9zWPXBJ7oNYz18+R0Yxx RW/5/mYY24QE19lwb/6kYeZMQSp3An7/1i9FlVRrFnksi7r5gvd2BTraUvDLZQC4Z4b/Ju KRQBFQBoNhD0xR+Q8ElhXa3Ck/4PZjU= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id B21B41FD7D; Mon, 24 Apr 2023 09:54:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1682330048; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IbUIip9bYjgV7vUOobjAK4CkjYy7pzt27Q+UhD49leA=; b=oqXh4VIQsJOuReKmBjH719UnqhUQho0yT9/lXAcs6sM4P5XZVG1maJoOQv7MdohLUc5jp4 G4NxqRgV6OMESOXBfC7ppXJJ/NcF+nAR7mv4HlJ58BqsbtPD7fcTfzSlZdRE2viTR1bd24 hbh7mvXmq95z+3kxaTNXk7FhFL5ZczU= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 9457A1390E; Mon, 24 Apr 2023 09:54:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 9WhPIcBRRmQ+HAAAMHmgww (envelope-from ); Mon, 24 Apr 2023 09:54:08 +0000 Date: Mon, 24 Apr 2023 11:54:07 +0200 From: Michal Hocko To: Baolin Wang Cc: akpm@linux-foundation.org, rppt@kernel.org, ying.huang@intel.com, mgorman@techsingularity.net, vbabka@suse.cz, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] mm/page_alloc: add some comments to explain the possible hole in __pageblock_pfn_to_page() Message-ID: References: <9fc85cce8908938f4fd75ff50bc981c073779aa5.1682229876.git.baolin.wang@linux.alibaba.com> <0733a4cf57109a4136de5ae46fac83fb15bdd528.1682229876.git.baolin.wang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0733a4cf57109a4136de5ae46fac83fb15bdd528.1682229876.git.baolin.wang@linux.alibaba.com> X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: x4mgsc3yx9rhhuiepasyasuo3ra7xjer X-Rspamd-Queue-Id: 33CD8160007 X-HE-Tag: 1682330049-966833 X-HE-Meta: U2FsdGVkX19z74yjtmLi1uBBiJszB/nAGQitx8hU6QNP4NCWX7qZp1SU5LKsmRjfRjp2qrYe1jSmHIb27XroPZU/hHeQwL3mpz3qvhTtSDHyZr+qYlHSobq1G926O0CWnJ05d9qp3SrGyRyUBWA8P3oV6rFJoEz8KwQxkkuK9sK/0BwMc0EL3OsxbCc7VvUM+RIDatVu4Aq7ETmWSuAiNTphsYgYUXZBI5qGoqFfFirB2rOuFMLHMU6nPX0BjAqr0baXd3k2gMCqQpuq1zVmiCCuIq47KPaHVMU4Z5RYaBi1teNLfo+uIcUJSDtR8KsucCJQJjjb1lcMx4epv9pu8wccnXF2OHnI6NaJu3u2VyRnuD0Cx75Sxk5w401/4uKT2nbG7k4BLnCr+5kTXeKnqejOTBuJpHSj1KqSIqeAabKm+96se7QebXJ7hsy37XYCQ7jaqg6p6ieSzR53Jy+/IiH86kLLrhuesObu2Wvi12tEW8MRMueRhj0cp3BfEAHpMIhtX4HmmPSY2Sp/TnwQvithLJQbI8ue2m4n/JxU2fGw+xLVcIyfl2gfwzDGknzXf1gTx9/pOyzAWUXucgnm266sDpSW1F9/2Dlzr8bsOSJKCNOXUrHecCFHjK8pUmfoNZs4tkaZ3QbXLdXPySpEx4+HjkOsvbrhvhH+eit/sBtsqb9owVKo7V563o5TPri/Nnt/f7DyCcN1O0F+6Gp7hG+rC2qVrKrZRz5W10TM5mm/j34xnYLfATOtpnDwzEi+yyZlATqAH5lalVQdwRzwHrYZsBpepPBeTILWeNF6/hjJElK4ie9rZmAfTLTJkCYLNeVL3ok2V0cgZHBhn2aqoKInFIQTOSsIcBJ9q8Jr2P5uc6j4PDfY5VsTCKzD1Kqr2eGNHLmx5Lfncr1/RvRt1ElNk229e5Wj029hyihCuaMkfMEhvLZoYX8A86KK9/Ud6t4Usm+8aCyVdrVsJYh VARQpR3M i7uWu6+PepWJ03GUiWh3ljsalJsaENggwRpRznjV+KixCtGnRiL1cIwlaaXB6DyJsdoPxErg5eCGls2i2aKBw5BNg+0cgxi7cMz1ZYwdVlA625/DTV34wCl4n5ETvTSDkQvIVKlXf2Ef1yvAkLDolxnbDRYL9lvkfC3umDz9YSyvrSnY+JQWqFZV+Guya1Q2UGqW+IBMYm8UrkIEoUM/jfxlxIMnfaXQ1NtqzHsDV9o08gf4D9czaq1jLwiQY9Vz52zRvZUBRZlR7XfPfz4gpgndz2fdZTDoP90msO94vCzYMqeD/M9Gp6FVj6JpoeM1ZwMnKIECPodXqZGY11iizMfQnEMRlpaQbUwtk6zKTIzzYQnI= 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: On Sun 23-04-23 18:59:11, Baolin Wang wrote: > 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. > > 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/ Do I remember correctly you've had a specific configuration that would trigger this case? > Signed-off-by: Baolin Wang > --- > Changes from v1: > - Update the comments per Ying and Mike, thanks. > --- > mm/page_alloc.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 6457b64fe562..9756d66f471c 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1502,6 +1502,13 @@ 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 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. > + * This did not break anything until now, but be careful about this possible > + * issue when checking whether all pfns of a pageblock are valid. It is not really clear what you should be doing (other than to be careful which is not helpful much TBH) when you encounter this situation. If the reality changes and this would break in the future what would breakage look like? What should be done about that? > */ > struct page *__pageblock_pfn_to_page(unsigned long start_pfn, > unsigned long end_pfn, struct zone *zone) > -- > 2.27.0 -- Michal Hocko SUSE Labs