linux-kernel - Re: BUG: Bad page state in process swapper pfn:00000

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMuHMdWZutiNpGScEhCzgM70jJ+MZ1ErmKtNfMHVLDB+d5Lyzw@mail.gmail.com>
Date:	Wed, 11 Jun 2014 21:19:10 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Laura Abbott <lauraa@...eaurora.org>
Cc:	Russell King <rmk+kernel@....linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Linux-sh list <linux-sh@...r.kernel.org>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: BUG: Bad page state in process swapper pfn:00000

Hi Laura,

On Wed, Jun 11, 2014 at 7:32 PM, Laura Abbott <lauraa@...eaurora.org> wrote:
> On 6/11/2014 4:40 AM, Geert Uytterhoeven wrote:
>> With current mainline, I get an early crash on r8a7791/koelsch:
>>
>> BUG: Bad page state in process swapper  pfn:00000
>> page:ee20b000 count:0 mapcount:0 mapping:66756200 index:0x65726566
>> page flags: 0x74656b63(locked|error|lru|active|owner_priv_1|arch_1|private|writeback|head|swapcache
>> |reclaim|mlocked)
>> page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
>> bad because of flags:
>> page flags: 0x212861(locked|lru|active|private|writeback|swapcache|mlocked)
>>
>> I bisected it to
>>
>> commit 1c2f87c22566cd057bc8cde10c37ae9da1a1bb76
>> Author: Laura Abbott <lauraa@...eaurora.org>
>> Date:   Sun Apr 13 22:54:58 2014 +0100
>>
>>     ARM: 8025/1: Get rid of meminfo

>> -Truncating RAM at 40000000-bfffffff to -6f7fffff (vmalloc region overlap).
>> +Truncating RAM at 0x00000000-0xc0000000 to -0x6f800000
>
> I'm guessing this is the issue right there.
>
>         memory@...00000 {
>                 device_type = "memory";
>                 reg = <0 0x40000000 0 0x40000000>;
>         };
>
>         memory@...000000 {
>                 device_type = "memory";
>                 reg = <2 0x00000000 0 0x40000000>;
>         };
>
> Those are the memory nodes from r8a7791-koelsch.dts. It looks like the memory
> outside 32-bit address range is not being dropped. It was suggested to drop
> early_init_dt_add_memory_arch which called arm_add_memory and just use the
> generic of code directly but the problem is arm_add_memory does additional
> bounds checking. It looks like early_init_dt_add_memory_arch in
> drivers/of/fdt.c checks for overflow on u64 types but not for overflow
> on phys_addr_t (32 bits) which is what memblock_add actually uses.
>
> For a quick test, can you try bringing back early_init_dt_add_memory_arch
> and see if that fixes the problem:
>
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index e94a157..ea9ce92 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -27,6 +27,10 @@
>  #include <asm/mach/arch.h>
>  #include <asm/mach-types.h>
>
> +void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> +{
> +       arm_add_memory(base, size);
> +}
>
>  #ifdef CONFIG_SMP
>  extern struct of_cpu_method __cpu_method_of_table[];

Thanks, my board boots again after applying this quick hack.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/