Re: remap_pte_range

[Andrew Morton]

"Martin J. Bligh" <mbligh@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/