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 D0634C433F5 for ; Tue, 24 May 2022 20:23:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 43BE58D0005; Tue, 24 May 2022 16:23:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EEA78D0001; Tue, 24 May 2022 16:23:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 303B18D0005; Tue, 24 May 2022 16:23:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 225438D0001 for ; Tue, 24 May 2022 16:23:35 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id F185A1208C6 for ; Tue, 24 May 2022 20:23:34 +0000 (UTC) X-FDA: 79501761948.21.8A3D72F Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf24.hostedemail.com (Postfix) with ESMTP id D006C180025 for ; Tue, 24 May 2022 20:23:21 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 21456B81862; Tue, 24 May 2022 20:23:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 711B8C34100; Tue, 24 May 2022 20:23:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1653423811; bh=1TBccbNXXdkA4yggnTErP3z1KQ5YvTNhTlw2uX3PD+0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=p8uKByO78gwiPvUIrtEW+RfKKx4lPhiAP5F3d+Wq8yHlKPW5HK6fS/Hs0x6HMjtdX aUqaytSI5r/DeFrqaaLyeLhjGs+E3H0zChZ50QZRKRiBU7KsZ7TBZa8X/Yx8eCIHm4 /MROOd+wzqKIesHZFh49zCSmEQ3xemCYvb2Ndqng= Date: Tue, 24 May 2022 13:23:30 -0700 From: Andrew Morton To: Zi Yan Cc: Zi Yan , Qian Cai , David Hildenbrand , linux-mm@kvack.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, Vlastimil Babka , Mel Gorman , Eric Ren , Mike Rapoport , Oscar Salvador , Christophe Leroy Subject: Re: [PATCH] mm: fix a potential infinite loop in start_isolate_page_range(). Message-Id: <20220524132330.eaf1366967d2fa927fdaf995@linux-foundation.org> In-Reply-To: <20220524194756.1698351-1-zi.yan@sent.com> References: <20220524194756.1698351-1-zi.yan@sent.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D006C180025 X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=p8uKByO7; spf=pass (imf24.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-Stat-Signature: it93r5nnr63i8iut6wdar6hqfyyj7ddm X-HE-Tag: 1653423801-665022 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 Tue, 24 May 2022 15:47:56 -0400 Zi Yan wrote: > From: Zi Yan > > In isolate_single_pageblock() called by start_isolate_page_range(), > there are some pageblock isolation issues causing a potential > infinite loop when isolating a page range. This is reported by Qian Cai. > > 1. the pageblock was isolated by just changing pageblock migratetype > without checking unmovable pages. Calling set_migratetype_isolate() to > isolate pageblock properly. > 2. an off-by-one error caused migrating pages unnecessarily, since the page > is not crossing pageblock boundary. > 3. migrating a compound page across pageblock boundary then splitting the > free page later has a small race window that the free page might be > allocated again, so that the code will try again, causing an potential > infinite loop. Temporarily set the to-be-migrated page's pageblock to > MIGRATE_ISOLATE to prevent that and bail out early if no free page is > found after page migration. > > An additional fix to split_free_page() aims to avoid crashing in > __free_one_page(). When the free page is split at the specified > split_pfn_offset, free_page_order should check both the first bit of > free_page_pfn and the last bit of split_pfn_offset and use the smaller one. > For example, if free_page_pfn=0x10000, split_pfn_offset=0xc000, > free_page_order should first be 0x8000 then 0x4000, instead of 0x4000 then > 0x8000, which the original algorithm did. > > ... > > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1114,13 +1114,16 @@ void split_free_page(struct page *free_page, > unsigned long flags; > int free_page_order; > > + if (split_pfn_offset == 0) > + return; > + > spin_lock_irqsave(&zone->lock, flags); > del_page_from_free_list(free_page, zone, order); > for (pfn = free_page_pfn; > pfn < free_page_pfn + (1UL << order);) { > int mt = get_pfnblock_migratetype(pfn_to_page(pfn), pfn); > > - free_page_order = ffs(split_pfn_offset) - 1; > + free_page_order = min(pfn ? __ffs(pfn) : order, __fls(split_pfn_offset)); Why is it testing the zeroness of `pfn' here? Can pfn==0 even happen? If so, it's a legitimate value so why does it get special-cased?