[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+8MBbJjEUJKo2ip8bDzDRVbBT+yhzqZXV0BYP3X52OJ3zA6Pg@mail.gmail.com>
Date: Wed, 29 Jan 2014 15:07:11 -0800
From: Tony Luck <tony.luck@...il.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: Yinghai Lu <yinghai@...nel.org>, xen-devel@...ts.xenproject.org,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
david.vrabel@...rix.com, Dave Hansen <dave.hansen@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Kevin Hilman <khilman@...aro.org>,
Olof Johansson <olof@...om.net>,
Santosh Shilimkar <santosh.shilimkar@...com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] memblock: Add limit checking to memblock_virt_alloc
Hmmph. ia64 is broken too. git bisect says:
commit ad6492b80f60a2139fa9bf8fd79b182fe5e3647c
Author: Yinghai Lu <yinghai@...nel.org>
Date: Mon Jan 27 17:06:49 2014 -0800
memblock, nobootmem: add memblock_virt_alloc_low()
is to blame. But this patch doesn't fix it. Still dies with:
PID hash table entries: 4096 (order: -1, 32768 bytes)
Sorting __ex_table...
kernel BUG at mm/bootmem.c:504!
swapper[0]: bugcheck! 0 [1]
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.13.0-bisect-09219-g5e345db #10
task: a000000101040000 ti: a000000101040f10 task.ti: a000000101040f10
psr : 00001010084a2018 ifs : 8000000000000797 ip :
[<a000000100eea530>] Not tainted (3.13.0-bisect-09219-g5e345db)
ip is at alloc_bootmem_bdata+0x230/0x790
unat: 0000000000000000 pfs : 0000000000000797 rsc : 0000000000000003
rnat: a000000100dff0ee bsps: 0000000000000000 pr : 96669601598a95a9
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70433f
csd : 0930ffff00063000 ssd : 0930ffff00063000
b0 : a000000100eea530 b6 : a0000001005f4040 b7 : a0000001005f3e00
f6 : 000000000000000000000 f7 : 1003e0000000000000000
f8 : 1003e0044b82fa09b5a53 f9 : 1003e0000000000001680
f10 : 1003e0000000000000008 f11 : 1003e00000000000002d0
r1 : a0000001017ce170 r2 : a00000010158e0a0 r3 : a0000001015ced80
r8 : 000000000000001f r9 : 0000000000000664 r10 : 0000000000000000
r11 : 0000000000000000 r12 : a00000010104fe20 r13 : a000000101040000
r14 : a00000010158e0a8 r15 : a00000010158e0a8 r16 : 0000000006640332
r17 : 0000000000000000 r18 : 0000000000007fff r19 : 0000000000000000
r20 : a000000101727e98 r21 : 0000000000000058 r22 : a000000101616c98
r23 : a000000101616c00 r24 : a000000101616c00 r25 : 00000000000003f8
r26 : a000000100e901a8 r27 : a000000100f59480 r28 : 0000000000000058
r29 : 0000000000000057 r30 : 00000000000016d0 r31 : 0000000000000030
Unable to handle kernel NULL pointer dereference (address 0000000000000000)
swapper[0]: Oops 11012296146944 [2]
-Tony
On Tue, Jan 28, 2014 at 5:50 PM, Konrad Rzeszutek Wilk
<konrad.wilk@...cle.com> wrote:
> On Tue, Jan 28, 2014 at 02:47:57PM -0800, Yinghai Lu wrote:
>> On Tue, Jan 28, 2014 at 2:08 PM, Dave Hansen <dave.hansen@...el.com> wrote:
>> > On 01/28/2014 02:04 PM, Yinghai Lu wrote:
>> >> In original bootmem wrapper for memblock, we have limit checking.
>> >>
>> >> Add it to memblock_virt_alloc, to address arm and x86 booting crash.
>> >>
>> >> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>> >
>> > Do you have a git tree or cumulative set of patches that you'd like us
>> > to all test? I'm happy to boot it on my system, I just want to make
>> > sure I've got the same set that you're testing.
>>
>> This one should only affect on arm and x86 the 32 bit kernel with more
>> then 4G RAM.
>
> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
>
> It fixes the issue I saw with Xen and 32-bit dom0 blowing up.
>
>>
>> thanks
>>
>> Yinghai
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists