Re: Re: Verify Kernel Pointer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hayim, can you explain why it is mapped twice?

I don't remember my own example but I think the free frames were
those at physical addresses 0x0600 and 0x0800, and you allocated 8K
with vmalloc. Suppose vmalloc returned 0xC4801000.
So the virtual address 0xC4801000 is mapped to physical address
0x0800, and 0xC4801200 is mapped to physical addr 0x600.

Regaedless to this mapping the kernel maps the virtual address
0xC0000600 to physical address 0x600, and 0xC0000800 to physical
address 0x800.

Not that I think it is a wrong or impossible thing to do.

Hmmmm, if something like this happen for user space, I can understand.
But for kernel space? CMIIW, all those pages are actually inside same
memory address space, that is kernel space. Thus, even kernel itself
inside protected environment, IMHO kernel doesn't need to map a page
reserved for kernel usage several times with different virtual address.
Do I miss something here?

Why does it bother you?
What's strange in referencing the same frame from two different pages?

One set of pages map the RAM.
Another set of pages keep the vmalloced data.

IMHO, although the above address (0xC2100000) is in kernel address
space, it doesn't neccesarily mean there is a page table that maps
the page to that virtual address. Thus, unmapping the page is
conditional.

Please explain. When does the mapping from virtual 0xC2100000 to
physical 0x2100000 cease to exist?

Whoops, looks like I got wrong understanding here. I ask some friends on
#kernelnewbies IRC channel and it is confirmed that all the RAM pages
are mapped into kernel space (of course, until the all available kernel
address are take up, the rest are ).

So, to be consistent with I am saying above, 0xC210000 to 0x2100000
doesn't exist if the RAM is less than or equal to 32 MB. Since you
assume physical RAM is indeed 64MB, then the mapping must exist. Only
one case cease it IMHO, that if the user boot the kernel by giving
"mem=" a certain number below the real amount of installed RAM.

Somebody..again, feel free to CMIIW...

I wrote a module that does this upon startup:
    printk("Allocating\n");
    p = kmalloc(2000, GFP_KERNEL);
    printk("p = %p\n", p);
    p[0] = 100;
    printk("Freeing\n");
    kfree(p);
    printk("p = %p\n", p);

    printk("referening\n");
    printk("p[0] = %d\n", p[0]);

No kernel panic. So I guess kmalloc addresses are kept mapped.
(within the limitations of having enough RAM/VM etc. etc.)


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux