lmb_alloc() and page memory overlap

Prashant Bhole prashantsmailcenter at gmail.com
Wed Nov 30 00:21:07 EST 2011


Hi,
I am using custom 460ex board with kernel version 2.6.30.
I noticed that page_alloc() is returning a page whose memory
is already allocated by lmb_alloc() while unflattening the device
tree. As per my knowledge the memory allocated by lmb_alloc()
should be reserved till the end, right?

Some more explanation of what I observed:

unflatten_device_tree() allocates memory, which will be used
for "struct node" objects in the device tree. I obtained base
address of allocated memory in "unsigned long base_mem"

Now I executed the following code after the kernel booted properly.

---------------------------------------------------------------
extern unsigned long mem; // lmb_alloc() memory
struct page *test_page = virt_to_page(mem);
struct page *new_page = NULL;

while(1)
{
    new_page = NULL;
    new_page = alloc_page(GFP_KERNEL);
    if(!new_page)
    {
        printk("Allocation failed\n");
        while(1);
    }
    if(test_page == new_page)
    {
         printk("Memory already allocated by lmb_alloc\n");
         while(1);
    }
}
---------------------------------------------------------------

After many page allocations, I always hit the condition (test_page == new_page).
Am I doing anything wrong here?
Has anybody faced this kind of problem before?


I also noticed that lmb_dump_all() shows 2 regions overlapping (last two):

LMB configuration:
 rmo_size    = 0x30000000
 memory.size = 0x30000000
 memory.cnt  = 0x1
 memory[0x0]    0x0000000000000000 - 0x000000002fffffff, 0x30000000 bytes
 reserved.cnt  = 0x6
 reserved[0x0]  0x0000000000000000 - 0x00000000006bffff, 0x6c0000 bytes
 reserved[0x1]  0x0000000000ffa000 - 0x0000000000ffcfff, 0x3000 bytes
 reserved[0x2]  0x000000002fdd0000 - 0x000000002fddffff, 0x10000 bytes
 reserved[0x3]  0x000000002fde4000 - 0x000000002fde9fff, 0x6000 bytes
 reserved[0x4]  0x000000002fdeb060 - 0x000000002ffff768, 0x214709 bytes
 reserved[0x5]  0x000000002fdee000 - 0x000000002ffff769, 0x21176a bytes


Thanks,
Prashant


More information about the Linuxppc-dev mailing list