Messages in this thread | | | Date | Tue, 29 Jun 2004 17:30:37 -0700 | From | Andrew Morton <> | Subject | Re: remap_pte_range |
| |
"Martin J. Bligh" <mbligh@aracnet.com> wrote: > > I have no idea what remap_pte_range is trying to do here, but what it > is doing makes no sense (to me at least). > > If the pfn is not valid, we CANNOT safely call PageReserved on it - > the *page returned from pfn_to_page is bullshit, and we crash deref'ing > it. > > Perhaps this was what it was trying to do? Not sure. > > diff -purN -X /home/mbligh/.diff.exclude virgin/mm/memory.c remap_pte_range/mm/memory.c > --- virgin/mm/memory.c 2004-06-16 10:22:15.000000000 -0700 > +++ remap_pte_range/mm/memory.c 2004-06-29 17:15:35.000000000 -0700 > @@ -908,7 +908,7 @@ static inline void remap_pte_range(pte_t > pfn = phys_addr >> PAGE_SHIFT; > do { > BUG_ON(!pte_none(*pte)); > - if (!pfn_valid(pfn) || PageReserved(pfn_to_page(pfn))) > + if (pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn))) > set_pte(pte, pfn_pte(pfn, prot)); > address += PAGE_SIZE; > pfn++;
It seems OK as-is.
If the pfn is not valid then establish the pte to point at physical memory.
If the pfn _is_ valid then check PageReserved. If the page is reserved then establish a pte to point at it.
The slightly weird thing is that we do
pfn = phys_addr >> PAGE_SHIFT; ... pfn_pte(pfn);
to go from the physical address back to a masked&shifted version of the physical address. Maybe that operation is doing the wrong thing in your setup and we should go straight from the physical address to the pte value, like 2.4's mk_pte_phys().
- 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/
| |