[PATCH] Fix buf in zeromap_pud_range() losing virtual address

This patch fixes a nasty bug that took us almost a week to track down on
ppc64, introduced by the 4L page table changes, and resulting in random
memory corruption. All archs that rely on a PTE page's struct page to
contain the mm & address (in mapping/index) will be affected.

zeromap_pud_range() is one of these page tables walking functions that
split the address into a base and an offset. It forgets to add back the
"base" when calling the lower level zeromap_pmd_range(), thus passing a
bogus virtual address. Most archs won't care, unless they do the above,
since the lower level can allocate a PTE page.

Kudo's to Michael Ellerman too who spent that week running tests after
tests to track it down, since the only way we managed to get it to show
up was after about 1 to 2h of LTP runs ...

(Note: We are in _urgent_ need to consolidate all those page table
walking functions, they all do things in a subtely different way, with
different checks (sometimes redudant) and inconsitent with each other,
even within a given set of them. Hopefully, Nick has some work in
progress there).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>

mm/memory.c

@@ -1041,7 +1041,8 @@ static inline int zeromap_pud_range(struct mm_struct *mm, pud_t * pud,
 		error = -ENOMEM;
 		if (!pmd)
 			break;
-		error = zeromap_pmd_range(mm, pmd, address, end - address, prot);
+		error = zeromap_pmd_range(mm, pmd, base + address,
+					  end - address, prot);
 		if (error)
 			break;
 		address = (address + PUD_SIZE) & PUD_MASK;