From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1754587AbdCaHNq (ORCPT <rfc822;w@1wt.eu>);
        Fri, 31 Mar 2017 03:13:46 -0400
Received: from mx2.suse.de ([195.135.220.15]:57960 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750938AbdCaHNp (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 31 Mar 2017 03:13:45 -0400
Subject: Re: [lkp-robot] [mm, page_alloc] b7ef62aa8a:
 BUG:kernel_hang_in_boot_stage
To: Andrew Morton <akpm@linux-foundation.org>
References: <20170322043611.GJ26669@yexl-desktop>
 <59d71b35-d556-4fc9-ee2e-1574259282fd@suse.cz>
 <20170330154026.3ca919cf3b93da81c25724c4@linux-foundation.org>
Cc: kernel test robot <xiaolong.ye@intel.com>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        Mel Gorman <mgorman@techsingularity.net>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        David Rientjes <rientjes@google.com>,
        LKML <linux-kernel@vger.kernel.org>, lkp@01.org
From: Vlastimil Babka <vbabka@suse.cz>
Message-ID: <0b64033c-fcf2-ace1-ceff-3e0139f75bb0@suse.cz>
Date: Fri, 31 Mar 2017 09:13:40 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170330154026.3ca919cf3b93da81c25724c4@linux-foundation.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03/31/2017 12:40 AM, Andrew Morton wrote:
>> > BUG: kernel hang in boot stage
>> 
>> Thanks, I was able to reproduce and debug this.
>> Andrew, please apply the following -fix. There will be conflicts on later
>> patches, but with trivial resolution (pages -> free_pages). Thanks!
>> 
>> ...
>>
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -1977,6 +1977,9 @@ static void steal_suitable_fallback(struct zone *zone, struct page *page,
>>  		goto single_page;
>>  
>>  	pages = move_freepages_block(zone, page, start_type);
>> +	/* moving whole block can fail due to zone boundary conditions */
>> +	if (!pages)
>> +		goto single_page;
>>  
>>  	/* Claim the whole block if over half of it is free */
>>  	if (pages >= (1 << (pageblock_order-1)) ||
> 
> The result is a bit odd:
> 
> 	free_pages = move_freepages_block(zone, page, start_type,
> 						&movable_pages);
> 	/*
> 	 * Determine how many pages are compatible with our allocation.
> 	 * For movable allocation, it's the number of movable pages which
> 	 * we just obtained. For other types it's a bit more tricky.
> 	 */
> 	if (start_type == MIGRATE_MOVABLE) {
> 		alike_pages = movable_pages;
> 	} else {
> 		/*
> 		 * If we are falling back a RECLAIMABLE or UNMOVABLE allocation
> 		 * to MOVABLE pageblock, consider all non-movable pages as
> 		 * compatible. If it's UNMOVABLE falling back to RECLAIMABLE or
> 		 * vice versa, be conservative since we can't distinguish the
> 		 * exact migratetype of non-movable pages.
> 		 */
> 		if (old_block_type == MIGRATE_MOVABLE)
> 			alike_pages = pageblock_nr_pages
> 						- (free_pages + movable_pages);
> 		else
> 			alike_pages = 0;
> 	}
> 
> 	/* moving whole block can fail due to zone boundary conditions */
> 	if (!free_pages)
> 		goto single_page;
> 
> should we do `goto single_page' as soon as the move_freepages_block()
> call fails?  

Yeah, that would be more obvious. Thanks!