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 E53BEC433FE for ; Fri, 4 Nov 2022 11:46:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2EF566B0071; Fri, 4 Nov 2022 07:46:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29F896B0073; Fri, 4 Nov 2022 07:46:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18E396B0074; Fri, 4 Nov 2022 07:46:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 0620E6B0071 for ; Fri, 4 Nov 2022 07:46:04 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C6EED161533 for ; Fri, 4 Nov 2022 11:46:03 +0000 (UTC) X-FDA: 80095581006.23.75F2463 Received: from outbound-smtp25.blacknight.com (outbound-smtp25.blacknight.com [81.17.249.193]) by imf28.hostedemail.com (Postfix) with ESMTP id CECEFC0007 for ; Fri, 4 Nov 2022 11:46:02 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp25.blacknight.com (Postfix) with ESMTPS id BFEB8CAD77 for ; Fri, 4 Nov 2022 11:46:00 +0000 (GMT) Received: (qmail 3010 invoked from network); 4 Nov 2022 11:46:00 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 4 Nov 2022 11:46:00 -0000 Date: Fri, 4 Nov 2022 11:45:59 +0000 From: Mel Gorman To: Andrew Morton Cc: NARIBAYASHI Akira , vbabka@suse.cz, rientjes@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] mm, compaction: fix fast_isolate_around() to stay within boundaries Message-ID: <20221104114559.k3gwykhqgfaxv7yf@techsingularity.net> References: <20221026112438.236336-1-a.naribayashi@fujitsu.com> <20221027132557.5f724149bd5753036f41512a@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20221027132557.5f724149bd5753036f41512a@linux-foundation.org> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667562363; a=rsa-sha256; cv=none; b=4ce5WVd+HSeNrsvtgv4QiVLFxWnUqVnxcVBHaro/+Q+MD2v9VFBaJyWKrqQzA2AO3Qu3O7 VEXv71Hu5kahkYX0SmTQrYp0RqcW8SQfbFJQwNeEwzf8tsgQtq5k1RMAr/8kZCz1IF0Tjl Gv/g1Z8NSxe+2tu7wFtTvzcutPm8QOo= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.193 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667562363; 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; bh=C368g718EhmpUqOrEPcJEuiC9dYGgCAQl9ptDnWWSMo=; b=etQktjD6RMqZy/TWp0SCFAldJsuKkaXVeqtoRrOqFG4cx8smM7EPpPB3mBFkWZR9mg7Q2L NNvJ5NEZhw2Y7zs0WtzNGrUiRurp7PWnB4MnpHEIbeIjUc9Me+GEefqLbjYE5pT81i8n/K pvUOI2Fo/7UR1ZvY9dEAnySHkZFIAHk= X-Stat-Signature: naags8874co73xjfjwp6fjh53mfj8bba X-Rspamd-Server: rspam09 X-Rspam-User: X-Rspamd-Queue-Id: CECEFC0007 Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of mgorman@techsingularity.net designates 81.17.249.193 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net X-HE-Tag: 1667562362-495263 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 Thu, Oct 27, 2022 at 01:25:57PM -0700, Andrew Morton wrote: > On Wed, 26 Oct 2022 20:24:38 +0900 NARIBAYASHI Akira wrote: > > > Depending on the memory configuration, isolate_freepages_block() may > > scan pages out of the target range and causes panic. > > > > The problem is that pfn as argument of fast_isolate_around() could > > be out of the target range. Therefore we should consider the case > > where pfn < start_pfn, and also the case where end_pfn < pfn. > > > > This problem should have been addressd by the commit 6e2b7044c199 > > ("mm, compaction: make fast_isolate_freepages() stay within zone") > > but there was an oversight. > > > > Case1: pfn < start_pfn > > > > > > | node X's zone | node Y's zone > > +-----------------+------------------------------... > > pageblock ^ ^ ^ > > +-----------+-----------+-----------+-----------+... > > ^ ^ ^ > > ^ ^ end_pfn > > ^ start_pfn = cc->zone->zone_start_pfn > > pfn > > <---------> scanned range by "Scan After" > > > > Case2: end_pfn < pfn > > > > > > | node X's zone | node Y's zone > > +-----------------+------------------------------... > > pageblock ^ ^ ^ > > +-----------+-----------+-----------+-----------+... > > ^ ^ ^ > > ^ ^ pfn > > ^ end_pfn > > start_pfn > > <---------> scanned range by "Scan Before" > > > > It seems that there is no good reason to skip nr_isolated pages > > just after given pfn. So let perform simple scan from start to end > > instead of dividing the scan into "Before" and "After". > > Under what circumstances will this panic occur? I'd also like to see a warning or oops report combined with the /proc/zoneinfo file of the machine affected. This is to confirm it's an actual bug and not a suspicion based on code inspection and a simplification of the code. The answer determines whether this is a -stable candidate or not. Both Case 1 and 2 require that the initial pfn started outside the zone which is unexpected. The clamping on zone boundary in fast_isolate_aropund() is happening due to pageblock alignment as there is no guarantee that zones are aligned on a hugepage boundary. pfn itself should have been fine as it is the PFN of a page that was recently isolated. The Scan After logic should also be ok. In the context it's called, nr_isolated is the number of pages that were just isolated so pfn + nr_isolated is the end of the free page that was just isolated. The patch itself should be functionally fine but it rescans a region that has already been isolated which is a little wasteful but it is straight-forward and the overhead is probably negligible. -- Mel Gorman SUSE Labs