[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D71CE24.1090302@kernel.org>
Date: Fri, 04 Mar 2011 21:46:12 -0800
From: Yinghai Lu <yinghai@...nel.org>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>, linux-mm@...ck.org,
Russell King <linux@....linux.org.uk>
Subject: Re: [RFC] memblock; Properly handle overlaps
On 03/04/2011 08:05 PM, Benjamin Herrenschmidt wrote:
> Hi folks !
>
> This is not fully tested yet (I'm toying with a little userspace
> test bench, it seems to work well so far but I haven't yet tested
> the cases with no-coalesce boundaries which at least ARM needs).
>
> But it's good enough to get comments...
>
> So currently, things like memblock_reserve() or memblock_free()
> don't deal well -at-all- with overlaps of all kinds. Some specific
> cases are handled but the code is clumsy and things will fall over
> in many cases.
>
> This is annoying because typically memblock_reserve() is used to
> mark regions passed by the firmware as reserved and we all know
> how much we can trust our firmwares right ?
>
> I have also a case I need to deal with on powerpc where the flat
> device-tree is fully enclosed within some other FW blob that has
> its own reserve map entry, so when I end up trying to reserve
> both, the current memblock code pukes.
did you try remove and add tricks?
diff --git a/mm/memblock.c b/mm/memblock.c
index 4618fda..ba4ffdc 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -453,6 +453,9 @@ long __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size)
BUG_ON(0 == size);
+ while (__memblock_remove(_rgn, base, size) >= 0)
+ ;
+
return memblock_add_region(_rgn, base, size);
}
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/
Powered by blists - more mailing lists