[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <4AF9E4BD-58F0-4D12-A495-6192978790B6@oracle.com>
Date: Wed, 27 Mar 2019 04:26:07 -0600
From: William Kucharski <william.kucharski@...cle.com>
To: Meelis Roos <mroos@...ux.ee>
Cc: Ralph Campbell <rcampbell@...dia.com>,
LKML <linux-kernel@...r.kernel.org>, linux-mm@...ck.org
Subject: Re: CONFIG_DEBUG_VIRTUAL breaks boot on x86-32
The dmesg output you posted confirms that max_low_pfn is indeed 0x373fe, and it appears
that the value of phys_mem being checked mat be 0x3f401ff1, which translates to pfn 0x3f401,
at least if what's still in registers can be believed.
Since that is indeed greater than max_low_pfn, VIRTUAL_BUG_ON triggers:
VIRTUAL_BUG_ON((phys_addr >> PAGE_SHIFT) > max_low_pfn);
Looking at the call stack of
copy_strings_0x220
__check_object_size+0xef
that looks to translate to this sequence:
copy_from_user(kaddr+offset, str, bytes_to_copy)
check_copy_size(kaddr+offset, bytes_to_copy, FALSE)
check_object_size(kaddr+offset, bytes_to_copy, FALSE)
__check_object_size(kaddr+offset, bytes_to_copy, FALSE)
check_heap_object(kaddr+offset, bytes_to_copy, FALSE)
virt_to_head_page(kaddr+offset)
virt_to_page(kaddr+offset)
pfn_to_page(kaddr+offset)
__pa(kaddr+offset)
__phys_addr(kaddr+offset)
so it appears the address is "too high" for low memory at that point.
Powered by blists - more mailing lists