Re: Fwd: Problem with set_memory_rw

[KAMEZAWA Hiroyuki]

On Thu, 4 Feb 2010 10:09:57 +0200
Oleg Kutkov <elenbert@xxxxxxxxx> wrote:
> Thank for answer!
> But this is a very strange, because 0x0509940 - it a virtual memory
> address (i got it from System.map, this is a system call table, on my
> machine). set_memory_rw return zero, anyway. Maybe, system call table
> is much write protected, so i can't change attribute of memory page?
> One more interesting thing:
> 
> 
> 
> struct page *pg;
> pg = virt_to_page(addr);
> unsigned long page_addr;
> page_addr = (unsigned long) page_address(pg);
> 
> 
> addr - this is my virtual address (provided by System.map)
> But page_addr got another value!
> What wrong?
> Sorry, if my questions is to stupid.
> 

Below is only about virt_to_page() etc... (not about set_memory_rw())
Maybe my answer for set_memory_rw() was pointless.

I think system call table is on .rodata section and set_memory_rw() doesn't
allow change attributes on .rodata sections(not .text)
..I'm sorry if I'm wrong.

==
At first, Linux maps physical memory in linear mapping. virt_to_page(), 
page_address()..etc works for this linear mapping area.

AFAIK, in some arch?, kernel's text area is on outside of linear mapping area.

For example, ia64 has
  0xa00xxxxxxxxxxxxxxxxxx  for kernel text.
  0xe000xxxxxxxxxxxxxxxxx  for linear mapping.

Another example, x86 has
  0xffffffff80000000       for kernel text.
  0xffff880000000000       for linear mapping's base address.

I know base address of linear mapping area is represented as __PAGE_OFFSET
in many archs. please check.

Anyway, "what 0x0509940 is" depends on your arch. I think.
Maybe it's good to investigate how __pa() and __va() is implemented on your arch.


Thanks,
-Kame

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/