lkml.org 
[lkml]   [2003]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.5.74-mm2 + nvidia (and others)
Date
Hi,

can anyone tell me WHY the NV_PMD_OFFSET() should not work the way it is with
the new NVIDIA patch? For our memories here it is again:

#define NV_PMD_OFFSET(address, pgd, pmd) \
{ \
pmd_t *pmd__ = pmd_offset_map(pgd, address); \
pmd = *pmd__; \
pmd_unmap(pmd__); \
}

1.) For a 2 level pagetable it simply results in a:
pmd = *((pmd_t *) pgd);

So here the correct entry from the first page directory is copied into a
variable on the stack. No big deal, as the location of this entry is not
interesting for the further tablewalk, only its contents.

2.) So let's see what happens for a 3 level pagetable.
We get following code after expanding (most of) the macros:

a.) pmd_t *pmd__ = ((pmd_t *)kmap_atomic(pgd_page(*(pgd)), KM_PMD0) +
pmd_index(addr));
b.) pmd = *pmd__;
c.) kunmap_atomic(pmd__, KM_PMD0);

The most interesting part is the first line of it...
a.) Here the page number is extracted from the pgd entry and converted to a
pointer to a page_struct (pgd_page). Now the page is mapped (from the high
memory) into the lower memory (kmap_atomic). The index where the interesting
pmd entry is located in this page is extracted from the virtual address via
the pmd_index macro. With this the pointer to the pmd entry is calculated and
assigned to pmd__.

b.) Now this entry is simply copied into a variable located at the stack.
(Again not an issue, as the location of the variable is not of interest for
the rest of the tablewalk anymore.)

c.) At least the page that contains the pmd entry, too, is unmapped, but our
local copy on the stack stays...


So after both pieces of code the pmd entry is stored in a variable on the
stack and the further processing does not need to know where it came from, it
just needs its contents...

So please tell me where this is wrong...! I just can't see it...

Thank you all for all the work!

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

\
 
 \ /
  Last update: 2005-03-22 13:46    [W:0.069 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site