Re: [bugfix] try_to_unmap_cluster() passes out-of-bounds pte to pte_unmap()

[William Lee Irwin III]

William Lee Irwin III <wli@xxxxxxxxxxxxxx> wrote:
>> --- ./mm/rmap.c.orig	2005-05-20 01:29:14.066467151 -0700
>> +++ ./mm/rmap.c	2005-05-20 01:30:06.620649901 -0700
[...]

On Mon, May 23, 2005 at 05:14:06PM -0700, Andrew Morton wrote:
> I must say that I continue to find this approach a bit queazifying.
> After some reading of the code I'd agree that yes, it's not possible for us
> to get here with `pte' pointing at the first slot of the pte page, but it's
> not 100% obvious and it's possible that someone will come along later and
> will change things in try_to_unmap_cluster() which cause this unmap to
> suddenly do the wrong thing in rare circumstances.
> IOW: I'd sleep better at night if we took a temporary and actually unmapped
> the thing which we we got back from pte_offset_map()..  Am I being silly?

Not at all. I merely attempt to minimize diffsize by default. An
alternative implementation follows (changelog etc. to be taken
from the prior patch) in case it saves the time (however short) needed
to write it yourself.


-- wli

Index: mm2-2.6.12-rc4/mm/rmap.c
===================================================================
--- mm2-2.6.12-rc4.orig/mm/rmap.c	2005-05-20 01:44:18.000000000 -0700
+++ mm2-2.6.12-rc4/mm/rmap.c	2005-05-23 19:13:29.000000000 -0700
@@ -626,7 +626,7 @@
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
-	pte_t *pte;
+	pte_t *pte, *original_pte;
 	pte_t pteval;
 	struct page *page;
 	unsigned long address;
@@ -658,7 +658,7 @@
 	if (!pmd_present(*pmd))
 		goto out_unlock;
 
-	for (pte = pte_offset_map(pmd, address);
+	for (original_pte = pte = pte_offset_map(pmd, address);
 			address < end; pte++, address += PAGE_SIZE) {
 
 		if (!pte_present(*pte))
@@ -694,7 +694,7 @@
 		(*mapcount)--;
 	}
 
-	pte_unmap(pte);
+	pte_unmap(original_pte);
 out_unlock:
 	spin_unlock(&mm->page_table_lock);
 }
-
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/