[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YRM+qm66PfTUQNFL@casper.infradead.org>
Date: Wed, 11 Aug 2021 04:06:18 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Qian Cai <quic_qiancai@...cinc.com>
Cc: Mike Rapoport <rppt@...ux.ibm.com>,
David Hildenbrand <david@...hat.com>,
Mike Kravetz <mike.kravetz@...cle.com>,
Linux Memory Management List <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux-next: crash in alloc_huge_page()
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.
> [ 8107.262232][T62705] Unable to handle kernel paging request at virtual address fffffffffffffffc
These logs would be a lot easier to read if you snipped the irrelevant
timestamp and whatever this Txxxxx thing is.
Powered by blists - more mailing lists