Problem with accessing page tables

Problem with accessing page tables

[Ameya Mitragotri]

Hi,

 I wrote following piece of code to traverse the page table for a
particular
Kernel variable. But the PMD access is always a failure.

 I'm using Itanium 2 with linux-2.6.0-test5.
Any pointers will be really helpful. 
Thanks and regards,
Ameya

	pgd_t *pgd;
	pmd_t *pmd;
	pte_t *ptep, pte;
	unsigned long pfn;

	printk(KERN_EMERG "The address is %lx\n\n\n",address);

	pgd = pgd_offset_k(address);
	if (pgd_none(*pgd) || pgd_bad(*pgd))
		goto out;

>>	pmd = pmd_offset(pgd, address); <<<
One of the checks below fails because the call pmd_offset gives pmd 
With value o.

	if (pmd_none(*pmd))
		goto out;
	if (pmd_bad(*pmd))
		goto out;

	ptep = pte_offset_kernel(pmd, address);
	if (!ptep)
		goto out;
	pte = *ptep;
	pte_unmap(ptep);
	if (pte_present(pte)) {
		if (!write || (pte_write(pte) && pte_dirty(pte))) {
			pfn = pte_pfn(pte);
			if (pfn_valid(pfn)) {
				struct page *page = pfn_to_page(pfn);

				//mark_page_accessed(page);
				return page;
			}
		}
	}
	else
	{
		printk(KERN_EMERG "pte entry not present \n");
	}

out:
	printk(KERN_EMERG "At out \n");

Re: Problem with accessing page tables

[David Mosberger]

>>>>> On Sat, 8 Nov 2003 09:46:38 +0530, "Ameya Mitragotri" <ameya.mitragotri@wipro.com> said:

  >>> pmd = pmd_offset(pgd, address); <<<

  Ameya> One of the checks below fails because the call pmd_offset gives pmd 
  Ameya> With value o.

That means the PTE directory hasn't been allocated yet.  Perfectly
normal for memory that hasn't been accessed yet.

	--david

RE: Problem with accessing page tables

[Ameya Mitragotri]

>   Ameya> One of the checks below fails because the call 
> pmd_offset gives pmd 
>   Ameya> With value o.
> 
> That means the PTE directory hasn't been allocated yet.  
> Perfectly normal for memory that hasn't been accessed yet.

We passed the address of swapper_pg_dir and this is what we got.

Nov  8 12:29:35 i2 kernel: The swapper_pg_dir address is
a0000001008d6000
Nov  8 12:29:35 i2 kernel: The pgd offset is 280 address of pgd entry is
a0000001008d6000 value @ pgd entry is 2146033664
Nov  8 12:29:35 i2 kernel: The pmd offset is 201 pmd address is
e00000007fe9f008
value @ pmd is 0

Now I think the memory for the swapper_pg_dir has already been
allocated.
I still get PMD as 0.

Am I doing something fundamentally wrong?

Thanks
ameya

RE: Problem with accessing page tables

[David Mosberger]

>>>>> On Sat, 8 Nov 2003 13:27:02 +0530, "Ameya Mitragotri" <ameya.mitragotri@wipro.com> said:

  Ameya> We passed the address of swapper_pg_dir and this is what we got.

  Ameya> Nov  8 12:29:35 i2 kernel: The swapper_pg_dir address is
  Ameya> a0000001008d6000
  Ameya> Nov  8 12:29:35 i2 kernel: The pgd offset is 280 address of pgd entry is
  Ameya> a0000001008d6000 value @ pgd entry is 2146033664
  Ameya> Nov  8 12:29:35 i2 kernel: The pmd offset is 201 pmd address is
  Ameya> e00000007fe9f008
  Ameya> value @ pmd is 0

  Ameya> Now I think the memory for the swapper_pg_dir has already been
  Ameya> allocated.
  Ameya> I still get PMD as 0.

Again, that's normal for memory that hasn't been allocated yet.

  Ameya> Am I doing something fundamentally wrong?

I don't know.  What exactly are you trying to do?

	--david

RE: Problem with accessing page tables

[Ameya Mitragotri]

>   Ameya> Now I think the memory for the swapper_pg_dir has 
> already been
>   Ameya> allocated.
>   Ameya> I still get PMD as 0.
> 
> Again, that's normal for memory that hasn't been allocated yet.
> 
>   Ameya> Am I doing something fundamentally wrong?
> 
> I don't know.  What exactly are you trying to do?

Our assumption is that the addresses for the global variables 
will surely be allocated.
(e.g. &panic_timeout should always resolve to an available PGD,PMD,PTE
and
in the end to a page.)
But we see that it is not happening in our case. (In case of
swapper_pg_dir 
one page is already allocated so it should point to a valid page).
Any valid address which we have taken from System.map does not resolve
down to a 
valid PTE. (??)

The whole purpose of this being, We want to simulate the page tables at
user level
to analyse a crash dump (LKCD) on IA64. So we dump the page tables and
when
Lcrash (the user mode tool for analysing dumps) reads this dump, it can
seek the
page tables and access global variables accordingly. This also will help
us eventually 
in unwinding the dumped stack.

Thanks
Ameya

RE: Problem with accessing page tables

[David Mosberger]

>>>>> On Tue, 11 Nov 2003 10:32:42 +0530, "Ameya Mitragotri" <ameya.mitragotri@wipro.com> said:

  Ameya> Our assumption is that the addresses for the global variables
  Ameya> will surely be allocated.  (e.g. &panic_timeout should always
  Ameya> resolve to an available PGD,PMD,PTE and in the end to a
  Ameya> page.)

Nope, that's a bad assumption.  The kernel's page-table is strictly
needed only for vmalloc'd memory.  Whether or not it's used to map the
kernel itself, is architecture-specific.  In the case of ia64, we use
an identity-mapping for kernel memory (the kernel itself is pinned
into the data TLB), so no page-tables are used.

  Ameya> The whole purpose of this being, We want to simulate the page
  Ameya> tables at user level to analyse a crash dump (LKCD) on
  Ameya> IA64. So we dump the page tables and when Lcrash (the user
  Ameya> mode tool for analysing dumps) reads this dump, it can seek
  Ameya> the page tables and access global variables accordingly. This
  Ameya> also will help us eventually in unwinding the dumped stack.

In the 2.6 kernel, the kernel image is pinned into the D TLB at
address 0xa000000100000000.  This _usually_ maps to physical address
64MB, but under certain circumstances (e.g., lack of memory at 64MB,
kernel image replication for better NUMA-locality), it may map to some
other physical address.

	--david