Re: Linux-next: crash in alloc_huge_page()

From: Mike Kravetz <mike.kravetz@oracle.com>
To: Qian Cai <quic_qiancai@quicinc.com>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@redhat.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux-next: crash in alloc_huge_page()
Date: Wed, 11 Aug 2021 08:59:04 -0700	[thread overview]
Message-ID: <8f78bed9-a677-0e62-e517-ea82850c0bff@oracle.com> (raw)
In-Reply-To: <8379f7d5-5d89-ac37-be83-aaa185dd6c3c@quicinc.com>

On 8/11/21 7:25 AM, Qian Cai wrote:
> On 8/11/2021 10:11 AM, Mike Rapoport wrote:
>> On Wed, Aug 11, 2021 at 04:06:18AM +0100, Matthew Wilcox wrote:
>>> On Tue, Aug 10, 2021 at 10:22:37PM -0400, Qian Cai wrote:
>>>> and the page->lru has an address fffffffffffffffc for some reasons. Does it sound like some error code
>>>> had not been handled properly and had been propagated here instead? I tried reverting a few recent
>>>> commits for mm/hugetlb.c and mm/memblock.c without luck so far.
>>>
>>> Yes, ff..fc is going to be at offset 8 from the actual address, so
>>> that's -12 and -12 is ...
>>>
>>> #define ENOMEM          12      /* Out of memory */
>>>
>>> so something's returning ERR_PTR(-ENOMEM) instead of NULL.
>>
>> page is not initialized in alloc_buddy_huge_page_with_mpol() and after
>> commit 2cfa8b23744f ("mm-hugetlb-add-support-for-mempolicy-mpol_preferred_many-fix") we have 
> 
> Good catch, Mike! Pretty sure I missed to test that commit thought that was an old commit along
> with the rest of the mpol_preferred series.
> 
> It is a dream that one day mm tree could like other subsystem trees where "git tag --contains"
> would work to indicate which linux-next tags contains a particular commit to tell the timeline
> of it. Right now, we have those commits ID always changed and commit date is meaningless for
> mm commits in linux-next.
> 
>> This should fix it:
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 008662083fec..6337697f7ee4 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -2152,7 +2152,7 @@ static
>>  struct page *alloc_buddy_huge_page_with_mpol(struct hstate *h,
>>  		struct vm_area_struct *vma, unsigned long addr)
>>  {
>> -	struct page *page;
>> +	struct page *page = NULL;
>>  	struct mempolicy *mpol;
>>  	gfp_t gfp_mask = htlb_alloc_mask(h);
>>  	int nid;
>>  
>>

Thanks everyone!

Looks like clang already found this.  Andrew added this to his tree
yesterday:

https://lkml.kernel.org/r/20210810200632.3812797-1-nathan@kernel.org

-- 
Mike Kravetz